fix(docs): bump Starlight to 0.41 for astro 7 compat (fixes Workers build) - #362
Merged
Conversation
Keeps the astro 7.1.3 security upgrade (#356) and fixes the Cloudflare "Workers Builds: microvm" docs build, which has been red on main since that merge. Root cause was NOT astro: @astrojs/starlight@0.39.3 declares `peerDependencies.astro: ^6.0.0`, so a clean install (npm ci, as the Workers build runs) resolved astro 7 against Starlight's ^6 peer and failed. Starlight 0.41.0+ moved its peer to `astro ^7.0.2`, so bumping Starlight — not downgrading astro — is the correct fix. Verified: `npm ci && npm run build` in docs/ completes (73 pages, no peer warnings) with astro 7.1.3 + @astrojs/starlight 0.41.4. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
microvm | 26faa92 | Commit Preview URL Branch Preview URL |
Jul 23 2026, 01:28 AM |
astro 7.1.3 declares engines.node ">=22.12.0". The repo had no Node pin, so the Cloudflare Workers docs build used its default (older) Node and the astro 7 build failed there — the second half of why "Workers Builds: microvm" went red at the astro 6->7 bump (the first half, Starlight's ^6 peer, is fixed by the 0.41.4 bump in this PR). Local dev masked it (Node 22.20 already satisfies). Add docs/.node-version=22.12.0 (Cloudflare reads it from the build root) and declare engines.node so the requirement travels with the package.
…p/esbuild linux)
The Cloudflare Workers build failed `npm ci` with "Missing @emnapi/runtime and
@emnapi/core from lock file". Cause: the earlier lock came from a partial
`npm install @astrojs/starlight@...`, which resolved only my macOS platform's
native deps. The astro-7 / Starlight-0.41 bump pulls a newer sharp whose wasm
path (@img/sharp-wasm32) needs @emnapi, and Linux needs @img/sharp-linux-*
etc. — none of which the partial install wrote. npm ci passed locally (mac uses
native sharp) but failed on Cloudflare's Linux.
Fix: clean full regenerate (rm node_modules + lock, npm install). The lock now
carries all platforms' optional natives — @emnapi/{core,runtime},
@img/sharp-{linux,linuxmusl}-*, @esbuild/linux-*, @astrojs/compiler-binding-
linux-* — so `npm ci` is in sync on Linux. lockfileVersion 3 (npm 10.9.2 compat);
astro stays 7.1.3, Starlight 0.41.4. 0 vulnerabilities.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Keeps the astro 7.1.3 security upgrade (#356) and fixes the Cloudflare Workers Builds: microvm docs deploy, which has been red on
mainsince that merge (bisect-confirmed first-red at the astro-bump commit8993b6f).The failure was not astro's fault:
@astrojs/starlight@0.39.3declarespeerDependencies.astro: ^6.0.0, so a clean install (npm ci, as the Workers build runs) resolved astro 7 against Starlight's^6peer and failed. Local dev masked it (stalenode_moduleshad astro 6).@astrojs/starlight@0.41.0+ moved its peer toastro ^7.0.2, so the correct fix is to bump Starlight, not downgrade astro — vulnerabilities stay fixed.Change
@astrojs/starlight0.39.3→^0.41.4astrounchanged at7.1.3package-lock.jsonregeneratedDocs-only; no content or Go changes.
Verification
🤖 Generated with Claude Code