<!-- ccr-slack-attribution -->
_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 <noreply@anthropic.com>
We were ignoring major version updates for Dependabot updates of GitHub
Actions, so we are now several major versions behind on several actions.
Turning major version updates back on so we can update everything.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Dependency update configuration now includes major version updates.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Major version updates require more preparation and testing, so we only
want to update these on our schedule / if actually deprecated, not be
prompted as soon as a new major version comes out. We mostly want to
keep patch/minor updates so we can be aware of any vulnerability fixes.
