chore(deps): set pnpm minimumReleaseAge to 3 days (fixes DOC-315)#1091
Conversation
Add a pnpm-workspace.yaml with minimumReleaseAge: 4320 (3 days in minutes) so newly published versions of packages (including transitive dependencies) cannot be installed until they have been live on the registry for at least 3 days. Reduces supply-chain risk from compromised package releases that are typically detected and yanked within hours. pnpm only reads minimumReleaseAge from pnpm-workspace.yaml or .npmrc; the pnpm field in package.json is not honored for this setting. Co-authored-by: Dima Grossman <dima@grossman.io>
✅ Deploy Preview for docs-novu ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
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 |
The newly-added pnpm-workspace.yaml uses minimumReleaseAge, which was introduced in pnpm v10.16.0. The CI workflow was pinned to pnpm v9, which (a) does not support the minimumReleaseAge setting and (b) errors on a pnpm-workspace.yaml without a 'packages' field. Bumps pnpm/action-setup from v2 to v4 and pnpm from 9 to 10 so CI matches the version used for local development (pnpm 10.30.3). Co-authored-by: Dima Grossman <dima@grossman.io>
2 participants
What
Adds a
pnpm-workspace.yamlwithminimumReleaseAge: 4320(3 days, in minutes), and bumps CI to pnpm v10 so the setting is actually honored there.Why
minimumReleaseAge(pnpm docs) tells pnpm to refuse to install any package version (direct or transitive) that has been published to the registry less than the specified number of minutes ago.Most malicious package releases (typo-squats, compromised maintainer accounts, supply-chain attacks like the recent
chalk/debug/shai-huludincidents) are detected and yanked from the npm registry within hours. A 3-day delay means installs in this repo will not pull in such releases during the high-risk window immediately after publication.This is a "free" hardening — it requires no code changes and only causes friction when intentionally upgrading to a brand-new release.
Why a separate
pnpm-workspace.yamlinstead ofpackage.jsonpnpm only reads
minimumReleaseAgefrompnpm-workspace.yamlor.npmrc. It is not honored when placed under thepnpmfield ofpackage.json(only a fixed allow-list of settings likeoverrides,packageExtensions,patchedDependencies, etc. are read from there). Verified locally — see test notes below.CI bump
The PR checks workflow was previously pinned to pnpm v9, which:
minimumReleaseAgeat all (added in v10.16.0), so the setting would have been silently ignored on CI installs.pnpm-workspace.yamlthat omits thepackagesfield (ERR_PNPM_NO_PKG_MANIFEST … packages field missing or empty).Bumped
pnpm/action-setupfromv2→v4andversion: 9→version: 10, which matches the local development version (pnpm 10.30.3). pnpm v10+ treatspnpm-workspace.yamlas config-only whenpackagesis omitted.Notes
minimumReleaseAgewas added in pnpmv10.16.0; the repo (and now CI) uses pnpmv10.x, so it is supported.minimumReleaseAgeStrictis "on when the user explicitly configuresminimumReleaseAge" — so if a transitive dep has no version older than 3 days that satisfies its range, install will fail with a clear error rather than silently falling back. That is the desired behavior.Testing
pnpm installwith the new config — succeeds (lockfile already satisfies the constraint, since all currently locked versions are well over 3 days old).pnpm-workspace.yaml, temporarily replaced it withminimumReleaseAge: 525600000+minimumReleaseAgeStrict: trueand ranpnpm add -D is-odd@latest. pnpm correctly rejected withERR_PNPM_NO_MATCHING_VERSION(no version is younger than ~1000 years). Restored the file afterwards.Build and Lintworkflow passes after the pnpm-version bump (previous failure was the pnpm v9 incompatibility described above).Slack Thread