Error launching chrome from WSL

[dmondev]

I'm getting an error when trying to use open@7.3.0 in WSL in a project built with @open-wc, @web/dev-server

This error doesn't happen with open@7.2.1.

Steps to reproduce:

1. Create a new project using:

npm init @open-wc --type scaffold --scaffoldType wc --features linting testing demoing --typescript true --scaffoldFilesFor testing demoing --tagName ui-element --writeToDisk true --installDependencies npm cd ui-element

2. run with npm start

The following error is displayed.

[web-dev-server] Error: spawn wslvar ENOENT [web-dev-server] at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19) [web-dev-server] at onErrorNT (internal/child_process.js:469:16) [web-dev-server] at processTicksAndRejections (internal/process/task_queues.js:84:21) {
[web-dev-server] errno: 'ENOENT', [web-dev-server] code: 'ENOENT', [web-dev-server] syscall: 'spawn wslvar', [web-dev-server] path: 'wslvar', [web-dev-server] spawnargs: [ 'systemroot' ], [web-dev-server] cmd: 'wslvar systemroot', [web-dev-server] stdout: '', [web-dev-server] stderr: '' [web-dev-server] }

[sindresorhus]

// @Pytal @tim-stasse

[Pytal]

@dmondev Which distro are you using?

Also what's the output for which wslvar and which powershell?

[dmondev]

both which wslvar and which powershell return empty from WSL.

Here is some additional info: WSL distro: Ubuntu 18.04.5 LTS Windows Ver: [Version 10.0.18363.1082]

Hope that helps.

[Pytal]

One more thing when you run powershell.exe does it open a powershell prompt?

[dmondev]

Yes, it does.

[littlebtc]

It seems open@7.3.0 requires

1. https://github.com/wslutilities/wslu to be installed.
2. powershell.exe exists in PATH.

Some new OS like Ubuntu had it included which some isn't (like Debian I am using).

[dmondev]

It seems open@7.3.0 requires

1. https://github.com/wslutilities/wslu to be installed.
2. powershell.exe exists in PATH.

Some new OS like Ubuntu had it included which some isn't (like Debian I am using).

This worked for me as well., (just installed wslu with apt-get install wslu).

Thank you very much, @littlebtc !!

[tobilg]

I'm having the same issue with the latest version of open as well when using WSL.

[noinkling]

Looks like I'm running into this problem too after updating some dependencies, specifically when running the Storybook dev server:

UnhandledPromiseRejectionWarning: Error: spawn wslvar ENOENT

Before this it would successfully pop open a browser window (I have the BROWSER env var set to my browser executable on the Windows side).

I'm on WSL1, legacy (pre-MS store version), Ubuntu 16.04. I don't think it's reasonable to expect people to have wslu/wslvar installed if it only comes by default on the latest distributions. However, even a noop (with a warning message or whatever) would be preferable to an unhandled error in my specific case, especially since unhandled rejections now throw an exception as of Node 15. Ideally it would just work like it did before though.

[tim-stasse]

@dmondev @noinkling Can you please confirm whether or not 204 fixes the issue for you?

[dmondev]

@dmondev @noinkling Can you please confirm whether or not 204 fixes the issue for you?

Hi @tim-stasse , I solved my issue by installing wslu in my WSL ubuntu dist.

I don't use open directly, but via open-wc. Is there a way to test this without having the package published to npm ?

I can easily switch between published versions in my package.json, but I don't know how to test this with a non published version.

I would be happy to help test this.

Thanks,

[tim-stasse]

@dmondev I believe you can clone the repo; switch to my branch; install node_modules npm install; and run tests npx ava: to manually verify that all the tests work for you.

If they don't, make sure to switch to the master branch and confirm whether or not all tests pass for you there—since you're environment might not be set-up correctly for all the tests to pass—so it may not be something that was introduced by this change (which would then also theoretically be fixable).

[dmondev]

@tim-stasse , I was able to run the test from master and your dev branch, after I removed wslu.

master failed immediately (19 tests failed).

from dev branch, the tests failed (18 tests failed), as well, but all of the 300 hundred tabs/windows were opened successfully :)

[tim-stasse]

@dmondev From my understanding—which I deduced from the source—you can safely ignore the "tests failed" message(s), as long as all the tabs are correctly opened.

I believe this is due to the tests being asynchronous and not being able to correctly handle that (@sindresorhus as the maintainer can hopefully confirm that assumption).

You should probably also make sure that all of the URL's are actually correct—as per each of the URL's in the tests—since the URL's get encoded and it's possible for them to be incorrect, even if the window successfully opens. Please note, that said; the URL encoding may mean the URL in the browser's address bar is different from the one in the test, but that also doesn't necessarily denote that it's incorrect—just that it's encoded, as it should be.

If that's the case, then it sounds like this change fixes your issue 🙂

[sindresorhus]

I believe this is due to the tests being asynchronous and not being able to correctly handle that (@sindresorhus as the maintainer can hopefully confirm that assumption).

Correct. I gave up on the automatic tests.

[noinkling]

@tim-stasse I cloned your fork, ran the tests and checked the URLs that were opened (hint: using the -s flag runs the tests in order which makes it a lot easier), and they all seemed good, including the incognito and editor stuff.

I actually had to change the specified Firefox path since mine is installed in a different location. The only potential weirdness I see is that when I keep the original path (which doesn't exist), open URL in specified app doesn't cause an error, but open URL in specified Windows app given a WSL path to the app does. Seems a little inconsistent.

Also I used Yarn's resolutions feature to test it out with Storybook, and it worked fine.