Search code examples
npmversioningsemantic-versioning

npm: Isn't package-lock.json lose its purpose if we all use package-lock.json?

This is a follow-up question to an answer of similar question asking whether package-lock.json is redundant if we only specify exact versions in package.json.

The answer states that package-lock.json protects us from transitive dependencies. Okay, so if semantic version range syntax e.g. ^ never exist in the first place and we all pin specific version only, it means package-lock.json is redundant, right?

Okay, I guess we need the range syntax in case of 2 dependencies depend on the same dependency with slightly different versions. But if we all use package-lock.json now, doesn't that mean all ranged version is treated as pinned version now? And if we all pin specific version only, it means package-lock.json is redundant, right?

Am I missing something?

Solution

  • Okay, so if semantic version range syntax e.g. ^ never exist in the first place and we all pin specific version only, it means package-lock.json is redundant, right?

    A lockfile still contains integrity hashes (and less importantly, resolved package source URLs) that prevent packages from being tampered with by the registry/package host, so it wouldn’t be redundant even in this case. Other than that, yes, when looking only at the version pinning part of lockfile functionality, lockfiles would be redundant if all versions were already pinned in all packages.

    Of course, in reality, dependency version ranges do exist and are important.

    But if we all use package-lock.json now, doesn't that mean all ranged version is treated as pinned version now?

    package-lock.json isn’t published with packages; it only applies to the end application. If every package published an npm-shrinkwrap.json instead, then yes, the end application would no longer be able to benefit directly from version ranges in its dependency tree’s package.jsons, but the separation would still serve a useful purpose: package.json would declare compatibility intent, and npm-shrinkwrap.json would represent a (tested, hash-checked) snapshot of that. (But once again, that’s just a hypothetical, and in practice npm-shrinkwrap.json is almost never used.)