ci: enable grouped dependabot updates for npm

[marc0olo]

Summary

There is no .github/dependabot.yml today, 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 frequently cannot resolve at all: #384 fails npm ci with ERESOLVE, as did #337 before it.

This enables npm version updates with three groups:

• astro / astro-security — astro + @astrojs/* in one PR, so dependabot resolves the family in a single pass. This is the fix for the chore(deps): bump astro from 7.1.6 to 7.3.2 #384 class.
• rest — everything else in one PR, so the weekly run stays at two PRs.

What this does not fix

Grouping fixes resolution, not code. A Starlight minor is a breaking release, so a grouped PR still fails the build check whenever the new version needs source changes (0.39 changed the autogenerate sidebar shape, 0.42 rewrote the mobile-menu markup). Those still get taken over by hand on an infra/ branch, which is also the only way to get a preview: preview-deployment.yml is skipped on dependabot PRs because their token is read-only.

.agents/upstream-tracking.md gains a section recording that, plus the two lockfile and rendering checks worth running when taking a bump over.

[Copilot]

🔵 Needs a closer look

Document the security-group limitation and coordinated-upgrade fallback.

Pull request overview

Enables grouped weekly npm Dependabot updates and documents validation procedures for dependency upgrades.

Changes:

• Groups Astro-related and remaining npm dependencies.
• Documents manual takeover, preview limitations, and validation checks.

File summaries

File	Summary
.github/dependabot.yml	Configures grouped npm updates; security updates may still split peer packages.
.agents/upstream-tracking.md	Documents upgrade procedures and validation checks.

Review details

Suppressed comments (1)

.github/dependabot.yml:28

• This security group only coalesces packages that have security updates themselves; it does not force Dependabot to update every matching peer. If an advisory affects only astro, this can still produce a one-package astro bump and the same peer-resolution failure this PR is intended to avoid. Keep the group if desired for simultaneous advisories, but document the limitation and the manual coordinated-upgrade fallback (or use another mechanism for security upgrades).

      astro-security:
        applies-to: security-updates
        patterns:
          - "astro"
          - "@astrojs/*"

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[marc0olo]

Feedback addressed:

• Security group does not force peer coalescing (Copilot, .github/dependabot.yml:28): correct, and now recorded in both the config comment and .agents/upstream-tracking.md. A security-updates group only combines family members that each carry an advisory, so an advisory against astro alone still arrives as a one-package PR that cannot resolve. The weekly version update is what keeps that rare, by leaving little room between the family's releases and what is committed. Group kept for the simultaneous-advisory case.

[Copilot]

🟢 Approval recommended

Final comments are minor documentation nits with no approval-blocking issues.

Review details

Suppressed comments (2)

.agents/upstream-tracking.md:245

• The dependency relationship here is backwards/ambiguous: astro's peer is @astrojs/markdown-remark, while @astrojs/mdx depends on that package (package-lock.json:267-294). Thus @astrojs/mdx 8 does not itself “satisfy” Astro's peer. State that the MDX release brings a compatible markdown-remark version, or name the actual package/range, so maintainers know what must move together.

cannot resolve at all: astro 7.2.10, for example, moved its
`@astrojs/markdown-remark` peer from an exact pin to `^7.3.0`, which only
`@astrojs/mdx` 8 satisfies, which only ships with Starlight 0.42. Grouping lets

.github/dependabot.yml:7

• These comments overstate the peer relationship: Astro does not pin an @astrojs/* set; the relevant peer in the current lockfile is the single @astrojs/markdown-remark package (package-lock.json:2786-2788). Describing a family of peers makes the reason for this grouping misleading; narrow the comment to that package.

  # touch one package at a time: an astro security bump alone cannot resolve,
  # because astro pins its @astrojs/* peers to a narrow range (see #384).

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite