Make Astro/EmDash version drift visible: version checks in emdash doctor + documented update path

[swissky]

The problem

EmDash declares astro: >=6.0.0-beta.0 as a peer dependency, and each release is developed and tested against one specific Astro version (currently the 7.0.x pin in pnpm-workspace.yaml). But a user's project owns its own Astro version, and nothing tells them when the two have drifted apart.

The failure mode is quiet: someone updates emdash regularly but stays on an old Astro (or the other way around), and at some point they hit a bug that only exists in their combination — like #1618, where emdash@0.22.0 broke on the Astro 7 Rust compiler. Support threads for these are expensive because the drift is invisible until something breaks.

Astro already solved the upgrade mechanics with npx @astrojs/upgrade (bumps core + all official integrations together). What's missing is the nudge that tells an EmDash user when to run it.

Proposal

Two small, additive pieces:

1. Version checks in emdash doctor

doctor currently checks DB health (migrations, collections, users). Add a version section:

• Read the installed astro version from the project's node_modules (or lockfile).
• fail if it's outside emdash's peer range.
• warn if it differs by a major from the version this emdash release was built against (embedded at build time from the workspace catalog), with the concrete hint: run npx @astrojs/upgrade.
• pass otherwise, printing both versions so support threads can start from facts.

No network calls, no auto-updating, no behavior change anywhere else. The user stays in control of their framework; they just stop being unknowingly on an untested combination.

2. A docs section on keeping the pair current

A short "Updating" page (or section) documenting:

• npx @astrojs/upgrade + pnpm add emdash@latest as the manual path,
• a Renovate/Dependabot snippet that groups emdash*, astro, and @astrojs/* into one update PR, so both are bumped and CI-tested together.

What this is not

Not a proposal to make emdash install or pin Astro. Astro majors break in user code (strict Rust compiler, Sätteri markdown, whitespace semantics), so silently pulling the framework along with a CMS update would turn working sites red on deploy. The peer range stays the contract; doctor just makes drift visible.

Happy to build both parts if this sounds right — the doctor change is small and self-contained.

[swissky]

One more piece that belongs to this story: create-emdash currently scaffolds no Renovate/Dependabot config, so a freshly created project never hears about updates again unless the user sets that up themselves.

Shipping a renovate.json in the template with a single grouped rule — emdash*, astro, @astrojs/* in one update PR — would give new projects the closest thing to WordPress auto-updates that a build-and-deploy stack can offer: the pair gets bumped together, the project's own CI tests the combination, and on git-connected Workers Builds the merge deploys itself. Users who don't run the Renovate app simply have an inert config file; no behavior change for them.

That would make the update story three complementary layers: doctor (diagnose drift locally), the scaffolded Renovate group (updates arrive as tested PRs), and the docs section tying it together. I've also opened #1889 for the awareness side (an update notice in the admin, mirroring what marketplace plugins already have).

Happy to include the template change in the same PR as the doctor check if that's preferred, or keep them separate.