chore: add npm supply-chain hardening#1
Conversation
📝 WalkthroughWalkthroughThis PR adds configuration for automated dependency management across npm and Bun ecosystems. Dependabot is configured to check for npm updates weekly, while npmrc and bunfig.toml enforce minimum release age thresholds to prevent premature adoption of newly published dependencies. ChangesDependency Management Configuration
🎯 1 (Trivial) | ⏱️ ~3 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.npmrc:
- Line 2: The repo adds min-release-age in .npmrc which requires npm >=11.10.0
but no npm version is pinned; update package.json to declare the required npm
version (use the engines.npm field or the packageManager field with a lockfile
version, e.g., "npm@>=11.10.0") and add a CI enforcement step to fail builds
when the runner npm version is older (validate npm -v or use the same
packageManager tool in CI); reference the package.json fields engines.npm and
packageManager and ensure CI checks the npm version before installing so
min-release-age is actually enforced.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2e0f6a5d-0b40-43eb-940d-c7fc5eed5c91
📒 Files selected for processing (3)
.github/dependabot.yml.npmrcbunfig.toml
| @@ -0,0 +1,2 @@ | |||
| ignore-scripts=true | |||
| min-release-age=3 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What npm CLI version introduced .npmrcsupport formin-release-age, and what is npm's behavior when this key is unknown or unsupported?
💡 Result:
npm CLI version 11.10.0 introduced support for the min-release-age key in .npmrc [1][2][3]. This feature was added via pull request #8965, merged in commit 66d6e11 on 2026-02-10, and released on 2026-02-11 [4][3]. Secondary sources confirm it requires npm v11.10.0 or above [5][6].
Citations:
- 1: https://github.com/npm/cli/blob/latest/CHANGELOG.md
- 2: https://github.com/npm/cli/blob/0a5756d5d06972dcf29cdee6978f5317dce92e6b/CHANGELOG.md
- 3: https://github.com/npm/cli/releases/tag/v11.10.0
- 4: npm/cli@66d6e11
- 5: https://socket.dev/blog/npm-introduces-minimumreleaseage-and-bulk-oidc-configuration
- 6: https://www.reddit.com/r/reactjs/comments/1taqlma/psa_how_to_set_minimum_release_age_for_your/
🏁 Script executed:
# Check for package.json and look for npm version constraints
git ls-files | grep -E "(package\.json|\.npmrc|pnpm-lock|\.nvmrc)" | head -20Repository: kitze/apple-crusher
Length of output: 83
🏁 Script executed:
# Look for CI configuration files
git ls-files | grep -E "(\.(github|gitlab|circleci)|\.travis|\.drone|Jenkinsfile|appveyor|\.github/workflows)" | head -20Repository: kitze/apple-crusher
Length of output: 86
🌐 Web query:
npm behavior with unknown or unsupported keys in .npmrc configuration file
💡 Result:
When npm reads a.npmrc file, it only recognizes configuration keys that are officially defined for npm. If your.npmrc contains unknown/unsupported top-level keys, npm behavior (as of npm v11) is: 1) npm warns about unknown keys starting in npm v11.2.0 - npm’s.npmrc documentation states that “Starting in npm v11.2.0, npm warns when unknown configuration keys are defined in.npmrc.” [1] - The warning format is illustrated (e.g., “warn Unknown user config "electron_mirror". This will stop working in the next major version of npm.”). [1] 2) Historically tolerated keys will eventually stop working (and may become hard errors) - The docs explicitly say that these unknown keys “were historically tolerated but are not officially supported” and that “A future major version of npm will treat unknown top-level keys as errors.” [1] - npm/cli issue discussions reiterate the intended deprecation and that unknown keys produce warnings with future versions. [2][3] 3) Recommended handling for “third-party” config keys - npm’s docs recommend that “Custom keys intended for third-party tools (for example, electron-builder) should not be placed in.npmrc.” [1] - Instead, it recommends using environment variables for cross-platform configuration. [1] Practical implication - In current npm v11.x, unknown.npmrc keys typically do not get applied as npm config; they mainly cause warnings and are slated for breakage in a future major release. [1] If you tell me the specific.npmrc keys you’re using (the exact lines), I can tell you whether they’re recognized npm config keys or likely fall into the “unknown/unsupported” category per npm’s documented behavior.
Citations:
- 1: https://docs.npmjs.com/cli/v11/configuring-npm/npmrc/
- 2: "Unknown user/project config" warnings starting in npm 11.2.0 npm/cli#8153
- 3: docs: clarify unsupported custom .npmrc keys and recommend alternatives npm/cli#8998
🌐 Web query:
npm v10 npm v11 npm v12 support for .npmrc keys and handling of unknown configuration keys
💡 Result:
npm v10 supports all standard.npmrc keys as listed in the official config documentation, with no warnings or errors for unknown keys[1][2]. npm v11 (starting from v11.2.0) introduced warnings for unknown/unsupported configuration keys in.npmrc files (user, project, global). Only officially supported keys are recognized; custom keys (e.g., electron_mirror for third-party tools) trigger warnings like "npm warn Unknown user config 'key'. This will stop working in the next major version of npm."[3][4][5][6][7]. Recommendations: Use package.json#config for package-specific settings (exposed as npm_package_config_* env vars, no warnings), environment variables, or CLI flags with --[4][5]. npm v12: No specific changes found in current releases (latest v11.13.0 as of 2026-05-13); warnings continue from v11[8][9][10][11]. A proposed breaking change to make unknown.npmrc keys hard errors (instead of warnings) is open in npm/cli#9276 (created 2026-04-23), targeted for a future major version (likely v12), along with errors for unknown CLI flags/abbreviations[12]. As of now, v12 docs not available, handling matches v11 (warnings). Supported keys are consistent across versions: auth-related (_auth, _authToken, etc., must be registry-scoped), registry, cache, etc. See full list in docs[1][4][2][13]. Custom/third-party keys never officially supported; prior tolerance ended with warnings in v11[4][5]. Use npm config ls to list active configs, npm config edit to edit.npmrc[14].
Citations:
- 1: https://docs.npmjs.com/cli/v10/configuring-npm/npmrc/
- 2: https://docs.npmjs.com/cli/v10/using-npm/config
- 3: "Unknown user/project config" warnings starting in npm 11.2.0 npm/cli#8153
- 4: https://docs.npmjs.com/cli/v11/configuring-npm/npmrc/
- 5: docs: clarify unsupported custom .npmrc keys and recommend alternatives npm/cli#8998
- 6: "Unknown user/project config" warnings starting in npm 11.2.0 npm/cli#8153
- 7: [DOCS] npm config: clarify unsupported custom user keys and document recommended alternatives npm/cli#8843
- 8: https://github.com/npm/cli/blob/45e44dd7ac2a3af815684ece3bdc99ada2f317f7/CHANGELOG.md
- 9: https://github.com/npm/cli/releases/tag/v11.12.0
- 10: https://github.com/npm/cli/releases/
- 11: https://github.com/npm/cli/releases/tag/v11.13.0
- 12: feat!: error on unknown configs, flags, and abbreviations npm/cli#9276
- 13: https://docs.npmjs.com/cli/v9/configuring-npm/npmrc
- 14: https://docs.npmjs.com/cli/v9/commands/npm-config
🏁 Script executed:
# Read package.json to check npm version constraints
cat package.jsonRepository: kitze/apple-crusher
Length of output: 1212
Require npm ≥11.10.0 for min-release-age guardrail.
The min-release-age key requires npm v11.10.0 or later. Without pinning npm (via engines.npm in package.json or packageManager field), developers on npm v10 will silently ignore this setting, and those on npm v11.0–v11.9 will receive warnings but still skip enforcement. Add an npm version constraint and enforce it in CI to ensure the guardrail is consistently applied.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.npmrc at line 2, The repo adds min-release-age in .npmrc which requires npm
>=11.10.0 but no npm version is pinned; update package.json to declare the
required npm version (use the engines.npm field or the packageManager field with
a lockfile version, e.g., "npm@>=11.10.0") and add a CI enforcement step to fail
builds when the runner npm version is older (validate npm -v or use the same
packageManager tool in CI); reference the package.json fields engines.npm and
packageManager and ensure CI checks the npm version before installing so
min-release-age is actually enforced.
1 participant
Adds repo-level package manager guardrails after the TanStack npm supply-chain incident:
These are intentionally behavior-changing install defaults, so this is opened as a PR instead of pushed straight to the default branch.
Summary by CodeRabbit