Finding your build scripts break after upgrading to npm@5 / node@8?

Howdies,

npm@5 & Node.js@8 have been one of the hotter news recently within the NodeJS community. First of all, sincere kudos to the team behind for having going out of their ways in developing and maintaining such cool products that provide us developers with so much comfort to carry on in our daily work 🙂

Now that we’re past the formality: anything new can potentially break an old thing or two. Unfortunately in my case, the upgrading broke all my production builds. I believe the issue was not with npm itself (no pun intended), but from more inconspicuous culprits, 3 of which I have identified so far:

1. My list of dependencies not having been cleaned up properly Believe it or not, in my package.json, I still retain some npm modules as old as the hills like WNdb which dates back to the Node@0.10 time. For some reason, these don’t get built properly by npm@5 (or it could be Node@8, sorry i’m too lazy to reproduce and tell for sure..). Luckily, I could do away with it, so it was simply a removal in the package.json file.Another instance: some modules kept failing to install. In my case, npm phantom did until I removed the entire node_modules directory and the package-lock.json file itself, then npm install all over again (pitifully, the installation process takes less time now, so, less time practicing my swordsmanship).
2. Prod and Dev dependencies apparently being mutually-exclusive now I don’t know who jammed the idea into my head at the time, but I explicitly set as default NODE_ENV=development on my staging server and NODE_ENV=production on my production one then *forgot all about it*. While set & forget is nice in many instances, this one was not, as npm install outputs different package-lock.json‘s on different environments; not only that, apparently when under --production, it removes all dev dependencies, and vice-versa (this one I haven’t got round to reproducing and confirming myself either, so I’d much appreciate any light shed on the case!). So what’s the problem? – you may ask – well, I do NODE_ENV=production npm run build on my production server, so my --production environments DO use --development dependencies. Ouch!
3. Optional dependencies getting carried over to package-lock.json, which hurts if they are OS-incompatible The 3rd issue I ran into was this. On my Mac, fsevents has been an optional dependency for a while now. The fact that it got carried over to the package-lock.json made my Ubuntu production server cry in agony. Of course there was no way in hell I could anticipate this as these optional modules hadn’t seemed to get dragged in with npm@4 and below.My temporary fix: do npm install --no-optional whenever an optional module seems to break my build.

   I’m totally not sure who was at fault here. I just know I never had to use the --no-optional flag) before…

Those were the 3 reasons my build scripts failed after the upgrade to npm@5. Another minor issue which didn’t trouble my builds but I think still is worth noticing was the “difference in order” of modules in my package-lock.json between an npm install on my local and one on my production. For example, after npm installing on my local, I got a package lock with this structure:

{ module1 },
{ module2 },
{ module3 }

whereas the same operation on my production server results in this structure:

{ module1 },
{ module3 },
{ module2 }

While it doesn’t kill my builds or whatsoever, the dude with OCD inside me cries inwardly every time..

Well, with all that said, obviously this post is by no means a complaint to npm or its wonderful creators. As said above, I’ve always appreciated their great work and awesome products. That is also exactly why I’d love to discuss the issues I’ve run into and my experience dealing with them. If I made any early assumption or any of you got a better explanation / solution to the issues discussed above, please lemme know in the comment!

Cheers,