withastro / astro · Issue No. 17371
Astro v7.0.6
Node v22+
System macOS / Linux
Package Manager pnpm
Output static
Adapter none
Integrations @astrojs/mdx
N/A (build / Node module resolution)
@astrojs/mdx statically imports satteri in its Sätteri MDX entrypoints, for example:
import {
mdxToJs,
// ...
} from 'satteri';
But packages/integrations/mdx/package.json does not list satteri in dependencies. It only declares optional peer @astrojs/markdown-satteri (which itself depends on satteri), and historically kept satteri in devDependencies only.
With pnpm's isolated node_modules and a normal Astro + MDX project (integrations: [mdx()] + an .mdx page):
satteri symlink beside @astrojs/mdxastro build often still succeeds by walking up to node_modules/.pnpm/node_modules/satteriastro build fails while compiling MDX:[ERROR] [vite] ✗ Build failed
Cannot find package 'satteri' imported from
.../node_modules/@astrojs/mdx/dist/satteri/index.js
at .../@astrojs/mdx/dist/vite-plugin-mdx.js
Reproduced on @astrojs/mdx@7.0.3. main still omits satteri from @astrojs/mdx dependencies.
Related: https://github.com/withastro/astro/pull/17072 addressed optional Sätteri loading for the Container API path, but does not declare satteri for the default Sätteri MDX processor path used when @astrojs/markdown-satteri is present (pulled in by astro itself on Astro 7).
astro build on an MDX page should succeed under pnpm without relying on an accidental .pnpm/node_modules/satteri link. satteri should be a declared dependency of @astrojs/mdx so pnpm links it into @astrojs/mdx's isolated node_modules.
https://github.com/grant/astro-mdx-satteri-undeclared-dep-repro
Minimal Astro project with:
astro.config.mjs → integrations: [mdx()]src/pages/post.mdx → MDX page compiled during astro buildpnpm install
pnpm repro
pnpm repro runs a real astro build twice:
.pnpm/node_modules/satteri present → build succeedsastro build fails with Cannot find package 'satteri' from @astrojs/mdx/dist/satteri/index.jsManual steps are also in the README.
Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.
The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.