1

Carrying on from this earlier question What is the role of the package-lock.json?

We make regular use of package-lock.json to pin our package versions (and to audit which registry they resolved from, as we use a private one).

As part of our CI/CD process, this has been a practice for many years. Now however, we've started to publish our own NPM packages - and a senior engineer is stating that "there's no value in using package-lock.json for libraries".

Their explanation was, that when included in another app's package.json that app will only use the semvar from the published package's own package.json, and the lock file is completely ignored / unused.

  1. Is this really the case?
  2. We fairly frequently encounter package changes that break semvar (not sure if this is because we develop and build on different platforms, or if the non-locked dependency chain has a semvar range that isn't pinned)? If our package.json versions are already pinned, are there other ways to avoid that?
  3. Is there still value in using the lock file for packages (even if it's to dual-build the app to detect drift)?
Michael
  • 7,348
  • 10
  • 49
  • 86

2 Answers2

3

I assume by publish you mean publishing to NPM, in that case

The difference is that package-lock.json cannot be published, and it will be ignored if found in any place other than the root project.

See Docs

When a library is added to an application using npm install, npm resolves the dependencies of the newly added library based on its package.json and updates the application's lock file to pin all the dependencies involved. Sharing the applications lock file will make sure everyone gets the same version of dependencies.

Keeping the lock file in the library might help during the its development i.e. everyone working on it will get the same dependencies.

Josnidhin
  • 12,469
  • 9
  • 42
  • 61
2

package-lock.json is a great help for the developers. Not only because everyone in the team (and the CI) gets the same (locked!) versions of the dependencies, but also because they don't waste time to regenerate the dependencies tree (when running npm install). This is why the npm documentation recommends committing the file into your repositories.

If you are using another published dependency that you don't control yourself, which you only install via npm, there is no lock file created for this dependency - the "responsibility" to properly version, specify the dependencies and release the package relies on the package maintainer. Therefore answer for question 1) is yes.

  1. The semantic versioning breaking cannot be really avoided fully - it relies on humans, and there will be mistakes made - it's a risk calculated in using other's people code. The only way I can see to keep your own development going is to pin the package to the last known working version, and wait for the patch provided by the maintainer of your dependency. Reporting the issue to them helps to speed up the process in most of the well-maintained repositories.

  2. See the first paragraph - yes there is a lot of value to keep the lock file. I am not sure however what do you mean by "detect drift".

kpsherva
  • 42
  • 1
  • 2