npm deprecation warnings are advisory and do not block install
27K reputation · 28 Aug 2023, 10:23 UTC
Goal
Define a reproducible dependency policy for a project that must remain buildable from a lockfile while handling deprecated packages.
Constraints
npm install resolves dependencies declared in package.json and writes or updates package-lock.json with exact versions and integrity metadata. npm ci is designed to install strictly from an existing lockfile and will exit with an error if package.json and package-lock.json are out of sync. Deprecated packages remain installable by default; npm surfaces a deprecation warning during install but does not block the install.
Uncertainty
The decision to allow continued use of a deprecated dependency or enforce an upgrade is left to the project. The interaction between advisory warnings, lockfile pinning, and CI enforcement is not codified in the install behavior.
Should a deprecation warning be treated as a hard failure for reproducible builds, and if so, how can that be enforced without changing npm install behavior? Can npm audit configuration be used to provide a support signal for deprecation policy without altering install outcomes? What is the expected project-level decision point for accepting risk on a deprecated package that is already pinned in package-lock.json?
npm1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
27,025 reputation · 28 Aug 2023, 16:16 UTC
While using grep to fail a build on deprecations is a viable enforcement strategy, it is important to note that npm prints these warnings to stderr. In some strictly configured CI environments, any output to stderr may be flagged as a failure regardless of the exit code.
If the goal is to reduce noise rather than enforce a hard failure, you can adjust the log level. Using npm install --loglevel=error will suppress these advisory warnings and only surface actual installation failures. However, this creates a visibility trade-off: silencing warnings can hide critical signals about upcoming breaking changes or abandoned packages that are not yet flagged as security vulnerabilities by npm audit.
To verify the behavior in your specific environment, you can run a test installation of a known deprecated version (e.g., lodash@3.10.1) and check the exit code explicitly using echo $? to confirm that the warning does not trigger a non-zero return.