[marc0olo]

There is no .github/dependabot.yml, so dependabot runs security updates only and those bump one package at a time. Astro releases astro and @astrojs/* in lockstep with narrow peer ranges, so a single-package bump inside that family can fail to resolve.

This is pre-emptive: #380 is fine. I checked it before opening this. The peer that breaks this pattern, @astrojs/markdown-remark, is declared optional by astro, and nothing here materialises it — this repo has no @astrojs/mdx and no Starlight. The range change that caused the trouble elsewhere also landed in astro 7.2.10, and #380 stops at 7.2.8:

astro	@astrojs/markdown-remark peer
7.1.6 (current)	7.2.2 exact
7.2.8 (#380)	7.2.4 exact
7.2.10	^7.3.0

That is luck about our dependency surface, not a property of the family. dfinity/developer-docs hit this shape twice (#337, #384) and had to take both over by hand; their fix is what this copies. We will meet it the first time an @astrojs/* package has to move with astro.

Groups

• astro / astro-security — astro + @astrojs/* in one PR, so dependabot resolves the family in a single pass.
• rest — everything else in one PR, so the weekly run stays at two PRs.

Deliberately not grouped

Checked rather than assumed, since over-coupling costs resolution freedom:

• preact — @astrojs/preact 6 peers it at ^10.6.5, a wide range. Not lockstep.
• sharp — an optional dependency of astro 7.2.8 at ^0.35.4. chore(deps): bump sharp from 0.35.3 to 0.35.4 #381 bumped it alone and resolved fine.

What this does not fix

Grouping fixes resolution, not code. A grouped PR still fails the build check whenever the new version needs source changes. Those still get taken over by hand.

Also note this turns on weekly version updates, which did not run before — expect up to two PRs a week where previously there were only occasional security ones.

Not included

package-ecosystem: github-actions. Our workflow uses: are SHA-pinned, so they go stale silently and dependabot could track them, but that is a separate decision from the astro resolution problem. Happy to add it here or in a follow-up if wanted.

🤖 Generated with Claude Code

[github-actions]

Skill Validation Report

No skill files were changed in this PR — validation skipped.

[marc0olo]

Closing — the evidence does not support this.

I opened this on the assumption that a single-package bump inside the astro family can fail to resolve and needs grouping to fix. That premise is right, but the conclusion was not: dependabot already coalesces the family by itself, with no config. From dfinity/icp-cli, which has a much tighter astro surface than this repo (Starlight + @astrojs/mdx + a direct @astrojs/markdown-remark):

chore(deps): bump sharp and astro in /docs-site
chore(deps): bump esbuild, @astrojs/starlight and astro in /docs-site
chore(deps): bump astro and @astrojs/starlight in /docs-site

and when an astro-only bump genuinely could not resolve, dependabot closed it itself — icp-cli#658, "Superseded by #665" — and the coalesced PR merged two minutes later. No human intervention.

So on the security-update path, which is the only path this repo uses, grouping buys nothing that is not already happening.

What this PR would actually have changed is turning on weekly version updates. That is a posture decision, not a fix, and for a site with no Starlight or mdx coupling it is not worth ~2 PRs a week.

For the record, since it is the question that started this: #380 was safe, and is merged. The peer that broke dfinity/developer-docs (@astrojs/markdown-remark) is declared optional by astro and nothing here materialises it, and the range change landed in astro 7.2.10 while #380 stopped at 7.2.8. Verified by merging it with main and running npm ci + npm run build + npm run validate clean.

If we later want to stop sitting on an old astro until an advisory forces a jump — which is roughly what 7.1.6 → 7.2.8 was — the answer is enabling version updates deliberately, and this config would be the right shape for it.