CODEWITHSUNDEEP
node.jsnpm
oligofren
oligofren

Reputation: 22963

When are you not supposed to use the shrinkwrap & lock files that NPM produces?

Recent NPM versions have started automatically producing package-lock.json files, making it easy for all the devs on a team to make reproducible builds. Previously, one had to manually instruct NPM to produce a npm-shrinkwrap.json file, so it's a lot more convenient now that this happens automatically.

But what are the cases for when you are not supposed to use these files? I am especially interested in this from the view of a package maintainer of open source software published on NPM.

This is what I have come up with so far:

Non-published software: any

(Only lives in a repo)

On teams that produce some internal non-published software, you can choose to use whichever lock file you prefer. Both will make development smoother.

Published software: depends

(to a registry like npmjs.org)

Applications: shrinkwrap

If you are developing a daemon or CLI app, ship it with a shrinkwrap file. A package-lock.json will not do as it won't be published with NPM packages.

Libraries: nothing?

Don't create a shrinkwrap file, ref npm-shrinkwrap.json is discouraged for libraries:

The recommended use-case for npm-shrinkwrap.json is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or devDependencies. It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates.

Upvotes: 1

Views: 796

Answers (1)

Alex Blex
Alex Blex

Reputation: 37048

Exactly what the docs say. package-lock.json is for apps. Libraries should rely on package.json and work with all versions of the dependencies within declared boundaries.

Purpose of the package-lock.json is dead simple - to lock dependencies to the exact versions once they were resolved. It makes sense only on application level, as applications are not supposed to be a dependency for anything else.

Libraries in contrast are not applications, and are expected to have apps that depend on them. The more versions of own dependencies a library supports the less chances of unresolvable version conflicts with other libraries. So package-lock.json is something completely opposite to what libraries should have.

Upvotes: 2

Related Questions