Caret range and package-lock.json: how to get latest non-breaking versions with them?

Question

I got what package-lock.json is standing for, but I don't understand how is caret range work after adding this file?

Say I have a package (my-module) that I want to have all new non-breaking versions without specifying new versions manually. I install latest version and this is the result in package.json file:

"my-module": "^4.1.1"

However package-lock.json is also getting updated with fixing the version of my-module to 4.1.1.

Next time a new version comes out of my-module: 4.1.2. Running npm i will not install it as the version in package-lock.json is fixed to the old version.

Question

How can I achieve that npm i will download latest non-breaking version of my-module without creating new package-lock.json file all the time? Did this file just invalidate using caret range?

Answer 1

We came up with the idea of using preinstall functionality of package.json.

So under in your package.json file under scripts tag you add: "preinstall": "npm update".

Since npm update only updates packages affected by the caret range syntax you can have both package-lock.json and latest updates.

Answer 2

While I'm not fond of just posting pieces of documentation verbatim, I feel it is the best source to explain why what you're asking for is exactly what package-lock.json was designed to NOT NECESSARILY DO:

1. package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json.

2. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

WHEN package.json is fed into npm i the result of the operation is a filesystem node_modules, consistent with all the dependencies as declared in the package.json file.

This operation DOES NOT produce the same result all the time: even when using the exact same package.json file. And there are good reason why npm i was designed to do this, specifically:

• If a new version of a direct semver-range package may have been published since the last time your packages were installed, and thus a newer version will be used.