certain "npm install" success

[SamBrabble]

We would like to automate our server builds, so that they run correctly every time.

I have noticed that sometimes "npm install" will fail.

One solution, on occasion, is to remove the the .npm and the .node-gyp folders. Should this be done every time then, in order to prevent possible problems?

If npm install is known to break, during major version upgrades ( i.e. from node 10 to 11 etc) , then shouldn't it be coded to clear it's cache automatically?

Another question is, how consistent are the npm modules across slightly different platform versions... Because maybe I could bundle them up, and copy them as a tar file onto the servers, INSTEAD of running "npm install". the problem with this, would be if even small differences in Ubuntu platform versions or software package versions will prevent this from working consistently.

Finally, there is yet another risk, that some package developer has released a bug, that morning. When we run "npm install", it will grab that version.

So, a whole variety of issues.

thanks for your help.

[rlidwka]

Should this be done every time then, in order to prevent possible problems?

Maybe.

Because maybe I could bundle them up, and copy them as a tar file onto the servers, INSTEAD of running "npm install".

Yes, you can. But you need to run npm rebuild after you do that in case any native modules will show up.

Finally, there is yet another risk, that some package developer has released a bug, that morning.

npm help shrinkwrap

[othiym23]

In general, the CLI's cache is much less likely to get corrupted by registry instability with versions of npm at 2 or higher. Also, the primary registry is a far more reliable piece of infrastructure than it was in late 2013. In general, it should be necessary to reset a CI server’s cache under very exceptional circumstances as of mid-2016.

One solution, on occasion, is to remove the the .npm and the .node-gyp folders. Should this be done every time then, in order to prevent possible problems?

Because node-gyp only uses .node-gyp to store header files used in building native modules, I’m not sure why it would ever be necessary to explicitly remove that folder, unless the download of the tarball that node-gyp extracts the files from failed partway. (That should be treated as a bug in node-gyp instead of npm.)

If npm install is known to break, during major version upgrades ( i.e. from node 10 to 11 etc) , then shouldn't it be coded to clear it's cache automatically?

There are no direct binary dependencies in the cache, only metadata and package tarballs. As @rlidwka says, your local projects will need to have npm rebuild run against them whenever the native module ABI version gets bumped. Otherwise, it shouldn’t be necessary to do anything in particular with the cache when moving between Node or npm versions.

Another question is, how consistent are the npm modules across slightly different platform versions... Because maybe I could bundle them up, and copy them as a tar file onto the servers, INSTEAD of running "npm install". the problem with this, would be if even small differences in Ubuntu platform versions or software package versions will prevent this from working consistently.

I would only do this if the build and deployment hosts have the same operating system, hardware, and distribution configuration. In general, though, it’s safe to tar up a built application, unpack it on the deployment host, and (again) run npm rebuild to rebuild any native dependencies in the project, and the deployment host should only need internet access to nodejs.org, to pull down the headers. (Also, some packages have optional dependencies, like fs-events, which will build on some architectures, like OS X, but will break on Linux or Windows, so watch out for those when tarring up built applications.)

In general, there doesn’t seem to be any new functionality to add here, and I believe the CLI team has addressed the issues that lead to cache corruption, so I’m going to close this feature request as addressed. Thanks for your time!