From 0d970b837062e6820844aa4637c04ea9db933f1a Mon Sep 17 00:00:00 2001 From: "claude[bot]" <209825114+claude[bot]@users.noreply.github.com> Date: Wed, 16 Sep 2026 10:24:04 +0200 Subject: [PATCH] fix(deps): add cooldown to npm Dependabot updates to satisfy pnpm minimumReleaseAge (#50417) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit _Requested by **Jonny Summers-Muir** · [Slack thread](https://supabase.slack.com/archives/C0429V78ACX/p1789496187445649?thread_ts=1789496187.445649&cid=C0429V78ACX)_ ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Chore / CI config fix (Dependabot supply-chain policy). ## What is the current behavior? Dependabot's `npm`-ecosystem pull requests fail our Vercel preview builds. `pnpm-workspace.yaml` sets `minimumReleaseAge: 4320` (3 days), which makes `pnpm install` reject any dependency version published more recently than 3 days ago as a supply-chain safeguard. Dependabot proposes the newest available version the moment it's released, so a Dependabot PR's pinned versions can be — and repeatedly have been — younger than pnpm's 3-day cutoff at the moment CI first runs. Concrete example: branch `dependabot/npm_and_yarn/npm_and_yarn-a6265761c1` (commit `2e988c6`), the `design-system` Vercel preview build fails because `pnpm install` rejects `@antfu/install-pkg@2.1.0` and `@types/d3-selection@3.0.12` under the minimum-release-age policy. This is not a one-off — it recurs across many Dependabot npm PRs (e.g. #50399, #49060, #49013). Note: while investigating, I could not find a pre-existing `package-ecosystem: npm` entry in `.github/dependabot.yml` despite the repo's long history of grouped `npm_and_yarn` Dependabot PRs — meaning the previous npm update cadence (grouping across directories such as `/`, `/apps/studio`, `/e2e/studio`) was apparently running under a GitHub-managed default rather than an explicit, in-repo config. This PR makes that configuration explicit so it's actually possible to attach a `cooldown` to it (see caveats below). ## What is the new behavior? Added an explicit `package-ecosystem: npm` entry to `.github/dependabot.yml`, covering the monorepo's workspace directories (`/`, `/apps/*`, `/packages/*`, `/blocks/*`, `/e2e/*`, matching `pnpm-workspace.yaml`'s `packages:` globs), with: ```yaml cooldown: default-days: 4 ``` A `cooldown` tells Dependabot not to propose a version until it has been out for at least that many days — 4 days here, one day above pnpm's 3-day `minimumReleaseAge` gate to leave margin for scheduling/CI latency. This means Dependabot's proposals are now aligned with pnpm's acceptance window: by the time a PR is opened and CI runs, the version has already cleared the age check, so `pnpm install` no longer rejects it. This fixes the root scheduling mismatch (Dependabot proposes instantly, pnpm requires 3 days of age) rather than weakening the supply-chain check itself — `minimumReleaseAge` and `minimumReleaseAgeExclude` in `pnpm-workspace.yaml` are unchanged. This is a pure CI/dependency-tooling config change with no dependency version bumps, so `pnpm-lock.yaml` did not need to be regenerated. ## Validation - YAML syntax: parsed `.github/dependabot.yml` with `yaml.safe_load` — valid. - pnpm accepts the config: ran `pnpm install --lockfile-only --filter design-system...` (the project named in the failing example) from a clean checkout; it printed `Verifying lockfile against supply-chain policies (3424 entries)... Lockfile passes supply-chain policies`, confirming `pnpm-workspace.yaml`'s `minimumReleaseAge`/`minimumReleaseAgeExclude` config (untouched by this PR) still parses and behaves correctly. - Did not attempt a full monorepo `pnpm install`/lockfile regen: not needed since no dependency versions changed, and a full workspace install is separately blocked in this environment by an unrelated `npm.jsr.io` 403 on `apps/studio`'s `@jsr/std__path` dependency. - Could not validate the new `directories` (plural/glob) `dependabot.yml` field against GitHub's live Dependabot config validator from this sandbox (no network path to it); it is a documented, GA `dependabot.yml` option, but worth a maintainer double-checking the "Insights > Dependency graph > Dependabot" config validation tab once this PR is open. ## Additional context Caveat for a maintainer with org-admin visibility: since no npm entry existed in version control before this PR, it's worth confirming there isn't a separate, org/enterprise-level Dependabot configuration also managing npm updates for this repo (which could now run alongside this new repo-level entry). If one exists, this repo-level entry should take precedence per GitHub's documented behavior, but it's worth a quick check in org Settings, Code security, to rule out duplicate/conflicting scheduling. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01BGhzwT3p6k35oEBJa8ivgH Co-authored-by: Claude --- .github/dependabot.yml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index edf2b0976ec..ec6ffff5911 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -6,3 +6,22 @@ updates: interval: 'weekly' cooldown: default-days: 7 + # `pnpm-workspace.yaml`'s `minimumReleaseAge: 4320` (3 days) rejects any + # dependency version younger than 3 days old during `pnpm install`. Without + # a cooldown, Dependabot proposes the newest release the moment it's + # published, so its PRs are structurally guaranteed to fail CI/Vercel until + # the proposed version happens to age past the pnpm gate on its own. This + # cooldown holds Dependabot's proposals back until they've already cleared + # (with a one-day margin for scheduling/CI latency) pnpm's minimum release + # age, so the version pnpm sees is always old enough to be accepted. + - package-ecosystem: 'npm' + directories: + - '/' + - '/apps/*' + - '/packages/*' + - '/blocks/*' + - '/e2e/*' + schedule: + interval: 'weekly' + cooldown: + default-days: 4