This is a follow-up question to an answer of a 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 existed in the first place and we all pinned specific versions only, that would make package-lock.json redundant, right?

Okay, I guess we need the range syntax in case 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 version ranges are treated as pinned versions now? And if we all pin specific versions only, it means package-lock.json is redundant, right?

Am I missing something?

This is a follow-up question to an answer of a 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 existed in the first place and we all pinned specific versions only, that would make package-lock.json redundant, right?

Okay, I guess we need the range syntax in case 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 version ranges are treated as pinned versions now? And if we all pin specific versions only, it means package-lock.json is redundant, right?

Am I missing something?

• npm
• versioning
• semantic-versioning

Share Follow edited Mar 11 at 3:03 Ry-♦ 226k5656 gold badges493493 silver badges499499 bronze badges asked Mar 8 at 23:42 M Imam PratamaM Imam Pratama 1,35711 gold badge1414 silver badges3333 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

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.)