in fact, to my surprise, I've just tested our app (v0.10.x in production) on v4.0.0 and all our unit tests pass, the server works...
I'm amazed. A single module had to be bumped (Elasticsearch@8) while we directly rely on 50+ third party modules... Our npm-shrinkwrap is 2600 lines long.
That's not really a sign of instability to me, but rather great work
mongodb and redis are two compiled modules and we didn't have problems with those. Honestly, there may be others, I don't even know!
We try hard to keep our dependencies up to date to limit the risks of an upgrade. We progressively apply dependencies updates to dev->staging->sandbox->production environments.
Was I worried when node.js forked? sure! but the situation is much better now. I think node.js can move forward smoothly now.
You seemingly have much more experience with Node than me. Perhaps my amateur anecdotes are just bad luck, but certainly my Bash scripts that talk to Node break frequently.
I think the npm project should document best practices, like when to use "*" version, when to use npm-shrinkwrap, etc... to limit problems.
NPM is a very powerful tool. In fact, it's our deploy tool: we run `npm install` on servers (private Sinopia npm repository) to deploy. But to do that, you must follow many many rules that are written nowhere.
We used to do this and it caused a lot of issues. Shrinkwrap is a must to keep versions stable. NPM and network unreliability can cause failed installs, as well as other issues.
Our first major improvement to this work flow was a tar of the app with all of the dependencies coupled with `npm rebuild` after unpacking. This worked quite well.
However, recently, we have switched to using Docker to generated this sealed packages which is working great.
We've never really had a problem... Our sinopia npm server is probably isolating some network problems, plus we don't start/update servers that often.
Our NPM workflow also ensures builds are easy to replicate. Most problems in development occur because of obsolete versions of some packages (our apps contain many private modules)... Clean npm-installs shields us from that in production.
I'm amazed. A single module had to be bumped (Elasticsearch@8) while we directly rely on 50+ third party modules... Our npm-shrinkwrap is 2600 lines long.
That's not really a sign of instability to me, but rather great work