Fix findNodeViaShell to run within the workspace folder

[slushie]

This change sets the cwd option for spawn() to be the current workspace folder when spawning a shell in findNodeViaShell. Without this change, the search will run from within the current directory of the parent process, which is / by default. This PR makes it possible for project-local node version configurations to be used with the extension when running tests.

Without this change, I am unable to use the Playwright extension because node is not available in my PATH globally. Instead, my shell is configured to set the PATH env var by reading a file in the current directory which points to the correct node version.

[mxschmitt]

Looks reasonable, just to make sure. Was this a regression for you? Since this method is new and was implemented as a fallback, probably not?

I created #407 so its always based on the workspace folder of the current test project.

[slushie]

Looks reasonable, just to make sure. Was this a regression for you? Since this method is new and was implemented as a fallback, probably not?

I created #407 so its always based on the workspace folder of the current test project.

Nice, thank you! <3

I am a new Playwright user, so I don't know offhand if this is a regression with the recent related changes. But with my setup based on per-directory config, I think its most likely that this wouldn't have worked at all before.

In fact, I was looking at making a follow-up PR (adding runtimeExecutable: findNode(...) near here) to handle the debug launcher which suffers the same problem of not finding the node executable. I'm happy to contribute that as well, but I think you've got the gist of it here ;)

[mxschmitt]

Looks reasonable, just to make sure. Was this a regression for you? Since this method is new and was implemented as a fallback, probably not?

I created #407 so its always based on the workspace folder of the current test project.

Nice, thank you! <3

I am a new Playwright user, so I don't know offhand if this is a regression with the recent related changes. But with my setup based on per-directory config, I think its most likely that this wouldn't have worked at all before.

In fact, I was looking at making a follow-up PR (adding runtimeExecutable: findNode(...) near here) to handle the debug launcher which suffers the same problem of not finding the node executable. I'm happy to contribute that as well, but I think you've got the gist of it here ;)

Thank you! Sounds like a great plan!