chore: upgrade astro to 7.2

[magnus-madsen]

Upgrades astro to 7.2.0 and @iconify-json/octicon to 1.2.32.

Worth noting up front that this is a smaller step than the version ranges suggest: ^7.0.3 was already resolving forward to 7.1.6, so the real move is 7.1.6 → 7.2.0, one minor. Same for octicon — ^1.2.29 was on 1.2.30.

The lockfile delta

Only two packages change version, and two transitive ones drop out:

	before	after
astro	7.1.6	7.2.0
@iconify-json/octicon	1.2.30	1.2.32
@rollup/pluginutils	5.4.0	removed
estree-walker	2.0.2	removed

vite stays at 8.2.0 — 7.2.0 asks for ^8.0.13 and the tree was already above that. Astro's engines.node is unchanged at >=22.12.0, so the >=22 in package.json and the 22.x/24.x CI matrix are both still fine.

Nothing to migrate

7.2.0 has no breaking changes and no deprecations. Its minor entries are all opt-in and none apply here: a session: false switch for trimming session code out of SSR bundles, experimental.incrementalBuild, a digest property for content-layer loaders, relative-path resolution for the logger entrypoint, and a widened AstroPrerenderer.render() return type. This site is static with no sessions, no content collections, and no custom logger or prerenderer, so astro.config.mjs is untouched.

The patch fixes are more relevant on paper — one of them corrects Astro.url.pathname formatting — but nothing here read that value, and the build output confirms nothing moved.

@shikijs/themes is deliberately left alone

4.4.3 is out and ^4.4.1 would have taken it, but taking it is a regression. Astro 7.2.0 pins shiki@4.4.1, which carries its own @shikijs/themes — so at ^4.4.1 the two dedupe to one copy, and at ^4.4.3 they split:

node_modules/@shikijs/themes            4.4.3   <- what CodeSnippet.astro imports
node_modules/shiki/.../@shikijs/themes  4.4.1   <- what Astro's shiki uses

That is 1.8M duplicated, and it hands 4.4.3 theme objects to a 4.4.1 highlighter. CodeSnippet.astro already notes that shiki resolves only through astro, and this is the other half of that: the theme range wants to track whatever shiki version astro ships, not run ahead of it. I built it both ways — the output is identical either way, so the newer themes buy nothing to offset the skew. It picks up 4.4.3 on its own once astro bumps shiki.

Checked

npm run check is clean across 26 files, and npm run build emits the same 10 pages plus the sitemap.

Beyond that, the whole of dist/ diffs byte-for-byte identical against a build from before the upgrade — so the one octicon in use (octicon:graph-24, on /documentation) and the light-plus/dark-plus highlighting both render exactly as they did. The dev server was smoke-tested separately: /, /faq/, /vscode/, /blog/, /get-started/ and /principles/ all 200.

Not addressed here

Two things I found and left:

• nanoid GHSA-2v37-7h3g-55p8 (high), reached through astro -> vite -> postcss. It is pre-existing — 3.3.16 is in the lockfile on master today — and unrelated to this upgrade, which neither caused nor fixed it. npm audit fix resolves it as a nested bump.
• TypeScript 6.0.3 → 7.0.2, a major, which deserves its own pass.

🤖 Generated with Claude Code