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.
Disconnect is the management/config of VMs. We use vagrant, which means I have to check out the repo onto the drive to get the config...
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.
I for one do all sharing of files between guest and host using Dropbox and git. I've found that shared volumes have many problems like the one you cite, and treating them like two separate machines is usually the easiest way for me. If I had two physical machines with the same configuration as my guest/host, I would use network-based sync, so that's what I do on my Windows host (gaming pc at home, laptop that needs to be work friendly) with my Arch guest VM.
A fleet of appropriately-powered OS X boxes is substantially more expensive, and a fleet of Linux machines can't be operated efficiently by the rank-and-file.
The node ecosystem in general is a mess; I don't think you can blame that on the OS. I did a node project recently and I've still not been able to get it to run on two seemingly identical systems in the same way.
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.
I understand how such things occur, but that's not an ecosystem I want to be involved in. If ~ frequently lets in breaking changes (and it does) then nobody should be using it--the entire point of having versioned dependencies is to prevent breaking changes from entering your system.
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.
I tried npm shrinkwrap, but that only procrastinates on the problem: now instead of having to unravel a mess of dependencies on installation, you have to unravel a mess of dependencies whenever you want to upgrade a package. But now instead of having to solve a dependency problem that a bunch of other people have head to solve, you've created your own unique dependency problem. Not to mention that this completely bloats your installations.
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.
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.