You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scoped while assessing v0.37.0. Not taken into that release.
Why "CI is green" doesn't mean what it usually means here
#442 shows 13/13 checks green, and Website build is not one of them. The PR was opened 2026-08-17; the website-build job in ci.yml (npm ci + astro build, catching bad frontmatter / broken content collections / dead internal links) postdates it. This PR's green checkmark predates the one gate that actually exercises what it changes.
This repo already has a concrete precedent for what a blanket npm update does to this site: a prior blanket npm update broke the build via a peer-major mismatch (@tailwindcss/vite vs vite, astro vs vite) — the fix that came out of it was "security fixes go in by name, verified with npm run build, not as a batch" (see the site's own dependency-update convention). A two-major-version Astro jump inside an auto-generated group PR is exactly the shape that convention exists to catch before merge, not after.
What actually needs to happen before this can merge
If it goes red: don't try to fix it inside the auto-generated PR. Read the Astro 6→7 and MDX 5→7 migration notes, then apply the upgrade by hand, by name, verified with npm run build locally before pushing — the same discipline already established for this site's dependencies.
If it goes green: still worth a manual npm run build + a look at the built output before merging two major versions of the framework the whole site runs on, rather than trusting the CI gate alone on its first real exercise of this exact scenario.
Why not in v0.37.0 either way
v0.37.0 is a Rust-binary release; the website ships independently of it. No reason to couple a two-major frontend migration to a backend trust-layer release with its own risk already.
Scoped while assessing v0.37.0. Not taken into that release.
Why "CI is green" doesn't mean what it usually means here
#442 shows 13/13 checks green, and
Website buildis not one of them. The PR was opened 2026-08-17; thewebsite-buildjob inci.yml(npm ci +astro build, catching bad frontmatter / broken content collections / dead internal links) postdates it. This PR's green checkmark predates the one gate that actually exercises what it changes.Inside the group:
astro6.1.10 → 7.2.9 (major),@astrojs/mdx5.0.6 → 7.0.8 (two majors),@astrojs/react5.0.2 → 6.0.4 (major), plus 13 minor/patch bumps.Why not merge-and-see
This repo already has a concrete precedent for what a blanket npm update does to this site: a prior blanket
npm updatebroke the build via a peer-major mismatch (@tailwindcss/vitevsvite, astro vs vite) — the fix that came out of it was "security fixes go in by name, verified withnpm run build, not as a batch" (see the site's own dependency-update convention). A two-major-version Astro jump inside an auto-generated group PR is exactly the shape that convention exists to catch before merge, not after.What actually needs to happen before this can merge
website-buildjob actually runs against it — right now it's absent from the check list, not passing.npm run buildlocally before pushing — the same discipline already established for this site's dependencies.npm run build+ a look at the built output before merging two major versions of the framework the whole site runs on, rather than trusting the CI gate alone on its first real exercise of this exact scenario.Why not in v0.37.0 either way
v0.37.0 is a Rust-binary release; the website ships independently of it. No reason to couple a two-major frontend migration to a backend trust-layer release with its own risk already.
Refs: #442