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?
Share edited Mar 11 at 3:03 Ry-♦ 226k56 gold badges493 silver badges499 bronze badges asked Mar 8 at 23:42 M Imam PratamaM Imam Pratama 1,3571 gold badge14 silver badges33 bronze badges1 Answer
Reset to default 2Okay, so if semantic version range syntax e.g.
^never exist in the first place and we all pin specific version only, it meanspackage-lock.jsonis 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.jsonnow, 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.)