Essentially, why do we even need package-lock.json and shrinkwrap?

Question

Before anything, I'd like to mention I do know what package.json, package-lock.json and npm shrinkwrap technically do and how they differ. These are thoroughly documented all over the internet.

I would like to understand better why package-lock.json was created, and why package.json is not enough.

• If my package.json specifies exactly foobar@1.2.3, it will always install exactly foobar@1.2.3. ⇒ I do not need package-lock.json.
• If my package.json specifies foobar@~1.2.3, then it means that I guarantee my lib works fine with any foobar lib equal or over 1.2.3. Then I should not have to worry which version a user npm installs. ⇒ I do not need package-lock.json.

It seems to me that package-lock.json was created for very pragmatic reasons, because every programmer carelessly writes foobar@^1.2.3 in their package.json without testing every 1.x.x version. Thus, adding package-lock.json is a way to say "I didn't test all the versions I claimed my lib works with, but at least I can guarantee it works with this specific version."

I understand package.json's format is not very expressive. In particular, it does not have a way to express a maximum version with which the lib may not work in the absence of testing (e.g. when a new version of one of the deps is published).

Solution A: Always use fixed versions of packages in package.json.

Drawback of A: npm may not have much opportunity to mutualize dependencies among packages.

Solution B: Use version ranges in package.json, but make sure every single version from the claimed range work. In addition, an exclusion list could even be used.

Drawback of B: It could be tedious to test in a exhaustive way. It is also a combinatorial explosion if we want to test every version of a given dep with every single version of all others deps.

Is the existence of package-lock.json an acknowledgement that there are no good solution for this problem, and having at least one functional set of dep versions is deemed good enough?

I'd be interested if you have seen relevant discussions about that topic.

Answer 1

This is an interesting question and SO may not be the right place for an open discussion about the benefits of package-lock.json.

There are several benefits as you have mentioned. (e.g.: Tighter package version control.) Details on the benefits can be found in the documentation.

I will say that one of the main benefits of package-lock is that it includes all of the dependencies down the entire stack. This helps with optimization of the package tree for eliminating redundancies while ensuring reproducible and exact package tree versions for deployment. From the docs:

As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read package.json files, and allowing for significant performance improvements.