|
|
|
|
|
by garthk
4033 days ago
|
|
'npm ls' might give you a clue. 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.