Help us pick: How should we lock dependencies after npm-shrinkwrap.json is deprecated?

[RandomByte]

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:

• UI5 CLI
• UI5 linter
• UI5 MCP Server

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.json today

The npm documentation originally recommended it for CLI tools, and we adopted it for two reasons:

1. Supply chain security: A shrinkwrap pins the full transitive tree, so a compromised release of a (transitive) dependency does not reach our users until we update and republish. This matters especially for global installs (npm install -g) and npx, where the consumer has no lockfile of their own. The latter is common practice for running MCP servers.
2. Reproducibility: When a user reports a bug, the shrinkwrap guarantees we use the exact same dependency tree as the user. Issues caused by transitive updates are easy to reproduce.

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, use package-lock.json

We would drop npm-shrinkwrap.json and use package-lock.json instead, 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 bundleDependencies

An npm maintainer confirmed this to be the recommended replacement for CLIs that intend to ship locked dependencies:

bundleDependencies is the recommended path for shipping a CLI with a locked tree, including global installs and npx. [...] Tarballs are larger on download, but the installed footprint is the same.

With this option, we would bundle all required dependencies into the published tarball. npm install would 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.json in our CLIs, or if you have had problems with transitive updates in the past.

Thank you for your input.

[qualiture]

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...

[marianfoo]

I agree, I have never updated a single dependency from the UI5 CLI and those issues related to UI5 CLI where fixed pretty quick

[RandomByte]

Thanks for the input!

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...

We actually already do this today with the npm-shrinkwrap.json. So if you haven't noticed any issues due to that, we are already doing a good job 👍

[marianfoo]

You doing good job 😃

[qualiture]

What Marian says 😎