Symptom
When @dependabot rebase (or recreate) is requested on any npm / frontend Dependabot PR, Dependabot refuses with:
Dependabot can't access a private package registry without explicit configuration. Because of this, Dependabot cannot update this pull request.
Observed on #50, #52, #54, #58, #60 (all dependabot/npm_and_yarn/src/frontend/*). The uv (backend) and github-actions ecosystems rebase fine — only npm is affected.
Impact
- Frontend Dependabot PRs go stale whenever
main advances and cannot self-update. When they fall behind (e.g. after another frontend PR merges and rewrites package-lock.json), they get stuck.
- Each one currently has to be rebased by hand (reset branch to
main, re-apply the bump, npm install, force-push). That's error-prone: npm install re-resolves the whole tree and can drift unrelated transitives (seen on the typescript-6 PR, which cascaded the eslint toolchain).
Likely cause
.github/dependabot.yml has no registries: block. The project uses the public npm registry only (no .npmrc with a private registry is committed), so Dependabot shouldn't need one — this looks like Dependabot tripping over a package whose metadata resolution it can't complete and reporting it as a "private registry" problem.
Suggested fixes (investigate, pick one)
- Add an explicit public-npm
registries: entry referencing the npm registry in dependabot.yml and attach it to the npm update block — sometimes clears the false "private registry" error.
- Check for a stray/committed
.npmrc (frontend or repo root) referencing a non-public registry or auth token that Dependabot is honoring.
- Confirm no dependency points at a private/GitHub-Packages tarball that Dependabot can't reach unauthenticated.
Acceptance criteria
@dependabot rebase on a frontend npm PR succeeds (Dependabot pushes a rebased commit) instead of returning the private-registry error.
Severity: LOW (workaround = manual rebase). Discovered while clearing the Dependabot backlog (#50–#60).
Symptom
When
@dependabot rebase(orrecreate) is requested on any npm / frontend Dependabot PR, Dependabot refuses with:Observed on #50, #52, #54, #58, #60 (all
dependabot/npm_and_yarn/src/frontend/*). The uv (backend) and github-actions ecosystems rebase fine — only npm is affected.Impact
mainadvances and cannot self-update. When they fall behind (e.g. after another frontend PR merges and rewritespackage-lock.json), they get stuck.main, re-apply the bump,npm install, force-push). That's error-prone:npm installre-resolves the whole tree and can drift unrelated transitives (seen on the typescript-6 PR, which cascaded the eslint toolchain).Likely cause
.github/dependabot.ymlhas noregistries:block. The project uses the public npm registry only (no.npmrcwith a private registry is committed), so Dependabot shouldn't need one — this looks like Dependabot tripping over a package whose metadata resolution it can't complete and reporting it as a "private registry" problem.Suggested fixes (investigate, pick one)
registries:entry referencing the npm registry independabot.ymland attach it to thenpmupdate block — sometimes clears the false "private registry" error..npmrc(frontend or repo root) referencing a non-public registry or auth token that Dependabot is honoring.Acceptance criteria
@dependabot rebaseon a frontend npm PR succeeds (Dependabot pushes a rebased commit) instead of returning the private-registry error.Severity: LOW (workaround = manual rebase). Discovered while clearing the Dependabot backlog (#50–#60).