Context
Evaluate whether to swap Astro's markdown/MDX engine from the default unified() (remark/rehype) to Sätteri — "A Markdown pipeline forged in Rust for the JavaScript world." It's a Rust-based Markdown/MDX processor (not a site generator) exposing HAST/MDAST ASTs and a typed plugin API via napi-rs, with a WASM build.
Findings (as of 2026-06-29)
- It's a supported swap. Astro 6.4.4 exposes a pluggable
markdown.processor option, and there's an official @astrojs/markdown-satteri package. Astro core even has satteri-specific handling baked in. Adoption would be: markdown: { processor: satteri({ mdastPlugins: [...] }) }.
- Maturity risk.
@astrojs/markdown-satteri is v0.3.2 (published ~2026-06-23, pre-1.0, alpha/beta history).
- Scope. Satteri only touches the content-rendering path (
src/content/** → HTML). It does NOT replace scripts/generate-markdown.js, which converts HTML → Markdown (opposite direction) for the Accept: text/markdown agent feature.
- Performance win is negligible at current scale (~10 posts); build-time markdown parsing is not a bottleneck.
- Compatibility risk = the deciding factor.
rehype-mermaid is a HAST/rehype plugin; Satteri uses its own mdastPlugins/native plugin API, so whether it runs unchanged is unverified. Dual-theme Shiki likely survives (Astro applies highlighting outside the processor) but needs a real build to confirm.
Decision so far
Stayed on unified() and migrated off the deprecated remarkPlugins/rehypePlugins config shape onto markdown.processor: unified({ rehypePlugins: [rehypeMermaid] }). The processor slot is now the clean seam to A/B Satteri later.
To revisit later
Links: https://satteri.bruits.org/ · https://github.com/bruits/satteri · @astrojs/markdown-satteri on npm
Context
Evaluate whether to swap Astro's markdown/MDX engine from the default
unified()(remark/rehype) to Sätteri — "A Markdown pipeline forged in Rust for the JavaScript world." It's a Rust-based Markdown/MDX processor (not a site generator) exposing HAST/MDAST ASTs and a typed plugin API via napi-rs, with a WASM build.Findings (as of 2026-06-29)
markdown.processoroption, and there's an official@astrojs/markdown-satteripackage. Astro core even has satteri-specific handling baked in. Adoption would be:markdown: { processor: satteri({ mdastPlugins: [...] }) }.@astrojs/markdown-satteriis v0.3.2 (published ~2026-06-23, pre-1.0, alpha/beta history).src/content/**→ HTML). It does NOT replacescripts/generate-markdown.js, which converts HTML → Markdown (opposite direction) for theAccept: text/markdownagent feature.rehype-mermaidis a HAST/rehype plugin; Satteri uses its ownmdastPlugins/native plugin API, so whether it runs unchanged is unverified. Dual-theme Shiki likely survives (Astro applies highlighting outside the processor) but needs a real build to confirm.Decision so far
Stayed on
unified()and migrated off the deprecatedremarkPlugins/rehypePluginsconfig shape ontomarkdown.processor: unified({ rehypePlugins: [rehypeMermaid] }). The processor slot is now the clean seam to A/B Satteri later.To revisit later
@astrojs/markdown-satterimaturity once it hits 1.0 / stabilizes.unified(...)→satteri(...)and runbun run build; verifyrehype-mermaidand dual-theme Shiki output.Links: https://satteri.bruits.org/ · https://github.com/bruits/satteri ·
@astrojs/markdown-satterion npm