4 ms·

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 modul

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

blowski 11y ago
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.
- morgante 11y ago
  Bash scripts talking to Node sounds like a recipe for disaster.
  - mbrock 11y ago
    Why?
  - eyko 11y ago
    Please explain.
- weddpros 11y ago
  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.
  - vkjv 11y ago
    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.
    - weddpros 11y ago
      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.
TheHydroImpulse 11y ago
Most of the instability is related to compiled modules. Hopefully they'll be updated to support v4.0.0 shortly.
- weddpros 11y ago
  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.

blowski 11y ago

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.

morgante 11y ago
Bash scripts talking to Node sounds like a recipe for disaster.
- mbrock 11y ago
  Why?
- eyko 11y ago
  Please explain.
weddpros 11y ago
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.
- vkjv 11y ago
  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.
  - weddpros 11y ago
    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.

TheHydroImpulse 11y ago

Most of the instability is related to compiled modules. Hopefully they'll be updated to support v4.0.0 shortly.

weddpros 11y ago
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.