+1 I was going to make a rather sarcastic comment that this is for "professional engineers", but is OS X only. Ubuntu on a VirtualBox on Windows for me.
I've not been able to run node apps because executables end up getting stored in /node_modules/, but if that is on a windows share, no executable flag is stored.
Resolving the FS differences has always been the biggest pain for me using windows as the core OS.
- SSH to linux box with node on it
- Edit files via Samba/CIFS from windows box
- Run node/iojs via nvm for the project on linux
- ???
- PROFIT!
Sounds like if either have to nest VMs (is that even possible?), check out the repo twice. Or have a config that is very different on windows vs everyone else.
Oh well... Maybe win 10 will support a Linux compatible FS.
Are you using npm shrinkwrap?
npm shrinkwrap isn't a solution, it's a temporary hack and it makes things worse in the long run. Maybe you're only working on new projects, but I work on things that will have to be maintained.
Most mysteries come down to loose dependency declarations and semver stuffups, sometimes in combination. One of your deps' deps takes a ~ on one of its deps, that dep makes a breaking change and changes its version from 0.3.2 to 0.4.0… boom. Your fresh npm install on workstation #2 inhales the breaking change and doesn't work, but workstation #1 still works fine.
Fix: temporarily shrinkwrap from workstation #1 while you wait for the maintainer of the package with the ~ dep on the 0.* package to change to a ^ dep.
It's a machine. It's a lot more predictable than you think.
And tracking down these versions by hand is not a reasonable solution: some of these libraries pull down dozens of dependencies, each with their own dependencies, and it's not feasible to read the docs for every single package to find breaking changes.
> Fix: temporarily shrinkwrap from workstation #1 while you wait for the maintainer of the package with the ~ dep on the 0.* package to change to a ^ dep.
If I have to rewrite my entire install script to pull from a specific machine, the package system is useless, and I'll switch to a package system which is competently managed. What you're describing isn't a fix, it's a workaround.
In a larger sense, one of the main motivations for using other people's libraries is that libraries should "just work" and not need to be debugged and tested. That's not an assumption you can make in the node ecosystem. There are reasons you might want to test libraries, such as if you're writing crypto, or critical code on which people's lives depend. But the issues in node's ecosystem aren't that, they're just developers not following very basic development practices.
I stand by what I said: the node ecosystem is a mess. You've told me how to fix the node ecosystem's mess (which I already new) but the fact is, I have better things to do than constantly trying to fix other people's messes.