3 ms·

Don't use shrinkwrap - this comes directly from Laurie Voss, COO of NPM Inc. In my own experience using npm shrinkwrap has been pretty bad. NPM has its own loc

Don't use shrinkwrap - this comes directly from Laurie Voss, COO of NPM Inc. In my own experience using npm shrinkwrap has been pretty bad. NPM has its own lockfiles now, similar to yarn. > It has a few problems of its own, notably surprising, quiet updates to the lock file when using the default options This I've never noticed. I'm genuinely curious how it would happen. The only way I imagine it might happen is if you do a fresh install with no cache and some of the packages have moved or changed on the registry. Do you happen to have more details?

fold_left 9y ago
Note that shrinkwrap and npm 5 lockfiles are identical, running npm shrinkwrap just renames the file.
Silhouette 9y ago
Some of its commands, notably install, can modify yarn.lock if it's out of sync with package.json, and I think that by default they still do so silently. You can override that modification with various options, but it seems to defeat the point of a tool whose main function is to ensure stable, repeatable builds if something on say your CI server or a developer's machine after a source control merge can wind up with a locally modified yarn.lock that doesn't fetch identical versions of all dependencies to what everyone else is using. Edit: Also thanks for the tip about npm's new locking mechanism. Apparently that arrived with NPM 5. I just checked, and we have developer machines here that were last updated well under a year ago and are still on NPM 3, and that had itself been installed along with something like the third new major version of Node in not much over a year. I don't know how anyone is supposed to do development intelligently while the most fundamental tools for things like dependency management are bumping a major version and radically changing how they do even the most basic and essential things literally every few months. :-(

fold_left 9y ago

Note that shrinkwrap and npm 5 lockfiles are identical, running npm shrinkwrap just renames the file.

Silhouette 9y ago

Some of its commands, notably install, can modify yarn.lock if it's out of sync with package.json, and I think that by default they still do so silently. You can override that modification with various options, but it seems to defeat the point of a tool whose main function is to ensure stable, repeatable builds if something on say your CI server or a developer's machine after a source control merge can wind up with a locally modified yarn.lock that doesn't fetch identical versions of all dependencies to what everyone else is using. Edit: Also thanks for the tip about npm's new locking mechanism. Apparently that arrived with NPM 5. I just checked, and we have developer machines here that were last updated well under a year ago and are still on NPM 3, and that had itself been installed along with something like the third new major version of Node in not much over a year. I don't know how anyone is supposed to do development intelligently while the most fundamental tools for things like dependency management are bumping a major version and radically changing how they do even the most basic and essential things literally every few months. :-(