Rolldown fails to resolve `@bruits/satteri-wasm32-wasi` — `satteri` eagerly imported even with zero Markdown files

Astro Info

Astro                    v7.1.6
Node                     v24.18.0
System                   Windows (x64)
Package Manager          npm
Output                   server
Adapter                  @astrojs/cloudflare
Integrations             unocss
                         @astrojs/vue

If this issue only occurs in one browser, which browser is a problem?

N/A — this is a build-time / bundler error, not browser-specific.

Describe the Bug

@astrojs/markdown-satteri (and its native dependency satteri) is unconditionally imported via a static top-level import in Astro's config schema, even when the project uses no Markdown or MDX files at all.

The static import

In packages/astro/src/core/config/schemas/base.ts (compiled: astro/dist/core/config/schemas/base.js), line 2:

import { satteri } from "@astrojs/markdown-satteri";

This import runs on every astro dev / astro build invocation, regardless of whether Markdown is configured or used.

The satteri() call is only used to supply the default value for markdown.processor:

}).default(() => satteri())

What happens at build time

When building a project that uses @astrojs/vue with Vue client islands (client:only="vue") — but zero Markdown files — Rolldown encounters satteri/browser.js in the module graph. That file imports @bruits/satteri-wasm32-wasi, which is a platform-specific optional dependency that npm skips on Windows.

Build error

Using secrets defined in .dev.vars
[ERROR] [vite] ✗ Build failed in 627ms
[vite]: Rolldown failed to resolve import "@bruits/satteri-wasm32-wasi" from
"C:/Users/.../node_modules/satteri/browser.js".
This is most likely unintended because it can break your application at runtime.
If you do want to externalize this module explicitly add it to
`build.rolldownOptions.external`

On some runs, the process terminates with exit code 3221226505 (Windows STATUS_STACK_BUFFER_OVERRUN) and outputs:

Assertion failed: uv__has_active_reqs(loop), file src\win\async.c

Conditions that trigger the bug

• Project has zero .md / .mdx files
• @astrojs/mdx integration is not installed
• The markdown config key is never set in astro.config.*
• Uses @astrojs/vue with a client island (client:only="vue") containing a non-trivial module graph (Tiptap editor, Vue Router)
• Running on Windows where @bruits/satteri-wasm32-wasi is not installed by npm

What's the expected result?

@astrojs/markdown-satteri and its native binaries (satteri, @bruits/satteri-*) should only be loaded lazily / on-demand when the project actually processes Markdown or MDX content.

Projects that do not use Markdown at all should never trigger resolution of the Sätteri module or its WASM/native binaries.

Suggested fix — convert the static import in base.ts to a dynamic import:

// Before (current — eager, always loaded):
import { satteri } from "@astrojs/markdown-satteri";

// After (lazy — loaded only when markdown.processor is needed):
const getSatteriDefault = async () => {
  const { satteri } = await import("@astrojs/markdown-satteri");
  return satteri();
};

Link to Minimal Reproducible Example

https://github.com/arcsynxae/astro-cloudflare-monorepo-repro

Participation

• I am willing to submit a pull request for this issue.