3 ms·

Without the package lock file, your build is not repeatable. In two years (or more likely, two weeks) someone new will check out your code, it will be broken ou

Without the package lock file, your build is not repeatable. In two years (or more likely, two weeks) someone new will check out your code, it will be broken out of the box, and the poor sod will have no idea why. More than likely they will blame you.

mirekrusin 7y ago
But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases. It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design.
- allover 7y ago
  > But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases. But package-lock is intended to be used at the project level. i.e. lock all package versions in the current project or app. That isn't "useless in most cases", it solves specifically the case it is meant to solve. > It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design. But you're stuffed if you need to rebuild the docker image later, or for example, go back to an old commit/release, create a 'support' branch to retrofit a change and build a new image. You want repeatability all the way down.
splix 7y ago
May be I'm missing something, but why dependency resolution cannot be deterministic? If you always choose a version specified in the config, or a highest version if few different versions of the same dependency are defined through some of intermediaries, you'd always end with the same set. AFAIK it's the strategy in Gradle for JVM projects, and a similar deterministic strategy is used by Maven.
- javagram 7y ago
  NPM resolution is not deterministic because package dependencies may be specified using SemVer, e.g. “~1.0.0” which may result in pulling 1.0.0, 1.0.1, 1.0.2, and so on - anything that matches 1.0.x specifier. The NPM ecosystem commonly uses these types of specifiers. Even if your own dependencies are all specified in “package.json” using exact versions, they almost certainly depend themselves on other versions (dependencies of dependencies, and so on) using the semver specifiers. That means whenever an author of that package publishes themselves, your resolved dependencies may change. The package-lock.json is simply a record of the exact dependency resolution graph based on the registry state that existed at the moment you generated it, so that you can reliably reproduce that graph a month or a year later. Otherwise it’s very common for NPM-based projects to have “NPM install” fail later on (or succeed, but create a bug or unit test failure) because some new version was added to the registry and created a compatibility issue or bug.

mirekrusin 7y ago

But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases. It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design.

allover 7y ago
> But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases. But package-lock is intended to be used at the project level. i.e. lock all package versions in the current project or app. That isn't "useless in most cases", it solves specifically the case it is meant to solve. > It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design. But you're stuffed if you need to rebuild the docker image later, or for example, go back to an old commit/release, create a 'support' branch to retrofit a change and build a new image. You want repeatability all the way down.

splix 7y ago

May be I'm missing something, but why dependency resolution cannot be deterministic? If you always choose a version specified in the config, or a highest version if few different versions of the same dependency are defined through some of intermediaries, you'd always end with the same set. AFAIK it's the strategy in Gradle for JVM projects, and a similar deterministic strategy is used by Maven.

javagram 7y ago
NPM resolution is not deterministic because package dependencies may be specified using SemVer, e.g. “~1.0.0” which may result in pulling 1.0.0, 1.0.1, 1.0.2, and so on - anything that matches 1.0.x specifier. The NPM ecosystem commonly uses these types of specifiers. Even if your own dependencies are all specified in “package.json” using exact versions, they almost certainly depend themselves on other versions (dependencies of dependencies, and so on) using the semver specifiers. That means whenever an author of that package publishes themselves, your resolved dependencies may change. The package-lock.json is simply a record of the exact dependency resolution graph based on the registry state that existed at the moment you generated it, so that you can reliably reproduce that graph a month or a year later. Otherwise it’s very common for NPM-based projects to have “NPM install” fail later on (or succeed, but create a bug or unit test failure) because some new version was added to the registry and created a compatibility issue or bug.