docs: clarify release age behavior for npm ci - #9844
Open
lreading-turnkey wants to merge 1 commit into
Open
Conversation
`npm ci` installs the versions recorded in the lockfile. It does **not** resolve versions or check release dates. Document that `--before` and `--min-release-age` configs do not affect `npm ci` in its command reference and generated configuration references. Refs: npm#9281
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Relates to #9281
The documentation should explicitly define the behavior described in #9281, regarding
npm ciignoring thebeforeandmin-release-ageconfig options.Here's why I think this is a good addition 😄
npm cihonored all config options in an.npmrcnpm ci, but it does not work as expected withbeforeandmin-release-agemin-release-agefornpm ci#9281This is also security adjacent. Most people configure release age requirements as a defense against supply chain attacks. Having this behavior undocumented likely leaves a lot of maintainers believing their CI systems are protected, when there's still an attack path. A malicious actor can update the lockfile with a malicious package that doesn't meet the release age requirements, and that will run in CI if the build system uses
npm ci.Longer term, I would also recommend logging a warning when there's a config that
npm cicannot honor.