Help us pick: How should we lock dependencies after npm-shrinkwrap.json is deprecated?
#1408
RandomByte
started this conversation in
Polls
Replies: 1 comment 4 replies
-
|
I would say Option B all the way; I think the UI5 toolchain (CLI, linter, MCP server) is consumed primarily via global install and npx, not as a dependency inside a project with its own lockfile. Option A would mean every 'npx ui5 lint' in a CI pipeline is a fresh, unverified dependency resolution against whatever versions happen to be current. Maybe worth considering for the UI5 team: with bundleDependencies, the UI5 team now owns the update cadence for transitive security patches, which is an operational commitment... |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
With npm v12, the npm team intends to deprecate
npm-shrinkwrap.json(npm/cli#8938).All three major CLI tools provided by the UI5 team are currently using this lockfile:
We would like to ask for community feedback on how to proceed with our lockfiles after the deprecation, since this also impacts users of our CLIs, especially those who install them globally or via
npx.Why we ship
npm-shrinkwrap.jsontodayThe npm documentation originally recommended it for CLI tools, and we adopted it for two reasons:
npm install -g) andnpx, where the consumer has no lockfile of their own. The latter is common practice for running MCP servers.Known drawbacks
There are multiple drawbacks for consumers of a package with a shrinkwrap, also outlined in npm/cli#8938. Consumers lack control over the transitive dependencies they install. For any fix in a dependency, the UI5 team has to publish a new release with an updated shrinkwrap. This means that security fixes and bug fixes in transitive dependencies reach users slower than without a shrinkwrap.
Our options
We are discussing two options on how to go forward for all three of our CLIs:
Option A: Drop
npm-shrinkwrap.json, usepackage-lock.jsonWe would drop
npm-shrinkwrap.jsonand usepackage-lock.jsoninstead, which only pins the development environment for our projects and is ignored by consumers.Consumers resolve dependencies at install time against the ranges in our project's
package.json. Depending on their package manager configuration, they would receive the latest versions of our dependencies, including transitive ones.We would lose both of the benefits mentioned above: the additional supply chain security and the reproducibility. Consumers have full control over dependencies.
Option B: Switch to
bundleDependenciesAn npm maintainer confirmed this to be the recommended replacement for CLIs that intend to ship locked dependencies:
With this option, we would bundle all required dependencies into the published tarball.
npm installwould not re-resolve them on the user's machine.Consumers would be in the same position as today regarding security and bug fixes in transitive dependencies. They would have to wait for a new release from the UI5 team.
Tell us what you think
Vote in the poll below, but also leave a comment with your thoughts.
We would love to hear from you if you have had any negative experiences with the
npm-shrinkwrap.jsonin our CLIs, or if you have had problems with transitive updates in the past.Thank you for your input.
9 votes ·
Beta Was this translation helpful? Give feedback.
All reactions