Astro Info
Astro v6.4.5
Vite v7.3.5
Node v22.22.0
System Linux (x64)
Package Manager npm
Output static
Adapter none
Integrations @astrojs/mdx (v6.0.3)
If this issue only occurs in one browser, which browser is a problem?
No response
Describe the Bug
The Markdown guide states that with extendMarkdownConfig: false, MDX uses the "Default unified() processor used with no plugins".
However, @astrojs/mdx always falls back to the global processor, regardless of the flag. In astro:config:done (packages/integrations/mdx/src/index.ts):
// remark/rehype plugins, remarkRehype, gfm, smartypants are all gated:
const markdownConfig = extendMarkdownConfig ? config.markdown : markdownConfigDefaults;
if (extendMarkdownConfig && isUnifiedProcessor(processor)) { /* ... */ }
if (extendMarkdownConfig && isSatteriProcessor(processor)) { /* ... */ }
// ...but the processor itself is not:
const processor = partialMdxOptions.processor ?? config.markdown.processor;
As a result, when the global config uses a non-default processor (e.g. satteri() from @astrojs/markdown-satteri with hastPlugins), those processor-level plugins are applied to .mdx files even though
extendMarkdownConfig: false is set.
Note: the JSDoc on the processor option of mdx() says it "Defaults to config.markdown.processor" unconditionally, so it's possible this is the intended behavior — in that case the docs should be updated instead, since they currently promise a default processor with no plugins. Either way the docs and the implementation currently contradict each other.
If the implementation is the side to fix, I'm happy to send a PR. A possible fix is to gate the fallback and use a fresh default processor:
const processor =
partialMdxOptions.processor ??
(extendMarkdownConfig ? config.markdown.processor : unified());
What's the expected result?
With extendMarkdownConfig: false (and no processor passed to mdx()), .mdx files should be rendered with the default unified() processor with no plugins, as documented — independent of the global markdown.processor.
Link to Minimal Reproducible Example
https://stackblitz.com/edit/withastro-astro-aujem2cb?file=astro.config.mjs
Participation
Astro Info
If this issue only occurs in one browser, which browser is a problem?
No response
Describe the Bug
The Markdown guide states that with
extendMarkdownConfig: false, MDX uses the "Defaultunified()processor used with no plugins".However,
@astrojs/mdxalways falls back to the global processor, regardless of the flag. Inastro:config:done(packages/integrations/mdx/src/index.ts):As a result, when the global config uses a non-default processor (e.g.
satteri()from@astrojs/markdown-satteriwithhastPlugins), those processor-level plugins are applied to.mdxfiles even thoughextendMarkdownConfig: falseis set.Note: the JSDoc on the
processoroption ofmdx()says it "Defaults toconfig.markdown.processor" unconditionally, so it's possible this is the intended behavior — in that case the docs should be updated instead, since they currently promise a default processor with no plugins. Either way the docs and the implementation currently contradict each other.If the implementation is the side to fix, I'm happy to send a PR. A possible fix is to gate the fallback and use a fresh default processor:
What's the expected result?
With
extendMarkdownConfig: false(and noprocessorpassed tomdx()),.mdxfiles should be rendered with the defaultunified()processor with no plugins, as documented — independent of the globalmarkdown.processor.Link to Minimal Reproducible Example
https://stackblitz.com/edit/withastro-astro-aujem2cb?file=astro.config.mjs
Participation