3 ms·

Stop pointing your package managers to the public registry. Unfortunately with NPM this is still awkward, because as soon as you try to shrinkwrap your project

Stop pointing your package managers to the public registry. Unfortunately with NPM this is still awkward, because as soon as you try to shrinkwrap your project, it doesn't just pin the version numbers, it also pins the full source location. That's in direct conflict with (and apparently takes precedence over) using one of the local caching proxies that would otherwise be a useful practical solution to this problem, and the situation gets even more complicated if you have people building at multiple locations and want each to have their own proxy. Yarn seems to have a better approach to this. It has a few problems of its own, notably surprising, quiet updates to the lock file when using the default options (IMHO a mistake since the big selling point of Yarn is its deterministic, reproducible behaviour) but at least you can do something resembling a local cache combined with something resembling version pinning, which is the ante for any sane build system.

jogjayr 9y ago
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. :-(

jogjayr 9y ago

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. :-(