Continuing attempts on WSL under Windows 10. I killed the bash prompt I had, and started a new one. This now seems to find the correct version of npm in preference to my Windows one, and npm install no longer fails instantly.
Unfortunately, it does still fail. After downloading a bunch of things, I get a bunch of errors associated with something called chromedriver. The first error message line says ERR! Linux-4.4.0-17134-Microsoft. Perhaps this means something has tried to figure out what sort of system it’s running on and doesn’t recognize what WSL reports? Possibly-informative later lines of the error message say ERR! code ELIFECYCLE and ERR! errno ENOENT. I can’t find anything in the node_modules directory relating to chromedriver; perhaps when something fails to install npm destroys the evidence? Scrolling back, I see that there’s an earlier sign of trouble: a line of the form > chromedriver@2.38.3 install [path to chromedriver module] (note: that path no longer exists in my filesystem) followed by a line of the form > node install.js followed by a blank line and then sh: 1: node: not found. After that comes a line beginning with “Vulcan” and then a big tree diagram of modules, then some dependency-related warnings, and then the errors I mentioned above.
[EDITED to add:] It turns out that on Ubuntu (which is the particular flavour of WSL I’m using) the nodejs package doesn’t provide a node executable because there’s another Ubuntu package that wants to call its executable node. So you need to install nodejs-legacy which I think just makes there be a symlink. And with that, npm install completes.
Now, of course, npm start fails. Meteor gets installed, we get a proxy started, but then three lots of Unexpected mongo exit code 100. Restarting. and some guesses at what Mongo might be unhappy about. And, actually, one of them looks super-plausible: this is all happening in an ordinary-Windows directory (via /mnt/c/… on WSL) and “MongoDB does not support filesystems like NFS that do not allow file locking.” So, time to put the whole thing inside WSL-land and see if it fares any better, I guess.
When the npm install option results in some errors, what I find most helpful is to try to install those things individually (where you can focus on just the errors relevant to a single thing)
So my next step if this were my machine would be:
1. look up the version of chromedriver it’s trying to install (in the package.json file)
2. I can see that it’s chromedrive@r^2.34.1
3. Try npm install chromedriver@^2.34.1
4. See what errors come up, do a google search for those errors and see if you find anything useful on stack overflow
You can resolve individual failed-to-download packages individually, and once you’ve done that for each package throwing errors, npm start should work.
Continuing attempts on WSL under Windows 10. I killed the bash prompt I had, and started a new one. This now seems to find the correct version of npm in preference to my Windows one, and npm install no longer fails instantly.
Unfortunately, it does still fail. After downloading a bunch of things, I get a bunch of errors associated with something called chromedriver. The first error message line says ERR! Linux-4.4.0-17134-Microsoft. Perhaps this means something has tried to figure out what sort of system it’s running on and doesn’t recognize what WSL reports? Possibly-informative later lines of the error message say ERR! code ELIFECYCLE and ERR! errno ENOENT. I can’t find anything in the node_modules directory relating to chromedriver; perhaps when something fails to install npm destroys the evidence? Scrolling back, I see that there’s an earlier sign of trouble: a line of the form > chromedriver@2.38.3 install [path to chromedriver module] (note: that path no longer exists in my filesystem) followed by a line of the form > node install.js followed by a blank line and then sh: 1: node: not found. After that comes a line beginning with “Vulcan” and then a big tree diagram of modules, then some dependency-related warnings, and then the errors I mentioned above.
[EDITED to add:] It turns out that on Ubuntu (which is the particular flavour of WSL I’m using) the nodejs package doesn’t provide a node executable because there’s another Ubuntu package that wants to call its executable node. So you need to install nodejs-legacy which I think just makes there be a symlink. And with that, npm install completes.
Now, of course, npm start fails. Meteor gets installed, we get a proxy started, but then three lots of Unexpected mongo exit code 100. Restarting. and some guesses at what Mongo might be unhappy about. And, actually, one of them looks super-plausible: this is all happening in an ordinary-Windows directory (via /mnt/c/… on WSL) and “MongoDB does not support filesystems like NFS that do not allow file locking.” So, time to put the whole thing inside WSL-land and see if it fares any better, I guess.
When the
npm installoption results in some errors, what I find most helpful is to try to install those things individually (where you can focus on just the errors relevant to a single thing)So my next step if this were my machine would be:
1. look up the version of chromedriver it’s trying to install (in the package.json file)
2. I can see that it’s chromedrive@r^2.34.1
3. Try
npm install chromedriver@^2.34.14. See what errors come up, do a google search for those errors and see if you find anything useful on stack overflow
You can resolve individual failed-to-download packages individually, and once you’ve done that for each package throwing errors,
npm startshould work.