Astro Info
Astro Info
astro: 5.17.1
@astrojs/mdx: 4.3.13
@astrojs/db: 0.19.0
Node: 24.8.0
OS: Linux
If this issue only occurs in one browser, which browser is a problem?
No response
Describe the Bug
When using @astrojs/db together with @astrojs/mdx, npm run build fails non-deterministically with:
Cannot access '__vite_ssr_import_8__' before initialization
The error occurs in the astro:content-asset-propagation Vite plugin during the transform phase and hits a different MDX file each run. The project imports MDX components in an astro layout file so that MDX files can use them without imports, and this is where the error is occurring.
During astro:build:setup, the @astrojs/db integration calls getTempViteServer() to create a temporary Vite server for seed file execution. This temp server shares the same plugin objects as the main build, and calling createServer() triggers configureServer on all of them — including astro:content-asset-propagation, which stores a devModuleLoader reference.
Later, during the main build's transform phase, the content-asset-propagation plugin checks if (devModuleLoader) and, finding it set, tries to evaluate MDX modules standalone via devModuleLoader.import(basePath). The temp server was created with ssr: { external: [] } (nothing externalized), so this evaluation hits a circular dependency between astro/dist/runtime/server/index.js and jsx.js. The circular import causes a const binding (Renderer2, aliased as __vite_ssr_import_8__) to be in the Temporal Dead Zone when __astro_tag_component__ tries to use it.
The devModuleLoader code path is only meant for the dev server — during build it should use the placeholder strategy instead, where placeholders are later replaced with actual CSS/JS by astroConfigBuildPlugin in post-build.
What's the expected result?
The build should complete successfully. The devModuleLoader should not be set (or should not be used) during build mode.
My Setup (Reproduction Context)
MDX files in my project don't import components directly. Instead, we have a MarkdownLayout.astro layout that imports ~16 components and passes them to the rendered content.
The @astrojs/mdx postprocess plugin injects __astro_tag_component__ calls into the compiled MDX for each of these component usages. When the contaminated devModuleLoader evaluates these MDX modules standalone during build, the __astro_tag_component__ import from astro/runtime/server/index.js triggers the circular dependency crash.
The bug is non-deterministic — it depends on module evaluation order during parallel processing. Some builds pass, others fail on different MDX files.
Workaround
I added a Vite plugin that wraps the content-asset-propagation plugin's transform during build to force options.ssr = false, which skips the devModuleLoader code path:
https://gist.github.com/webstackdev/4b20b42dd91b9698a942e61fcd357132
Related Issues:
#13085
#13152
Link to Minimal Reproducible Example
https://gist.github.com/webstackdev/4b20b42dd91b9698a942e61fcd357132
Participation
Astro Info
If this issue only occurs in one browser, which browser is a problem?
No response
Describe the Bug
When using @astrojs/db together with @astrojs/mdx, npm run build fails non-deterministically with:
Cannot access '__vite_ssr_import_8__' before initializationThe error occurs in the astro:content-asset-propagation Vite plugin during the transform phase and hits a different MDX file each run. The project imports MDX components in an astro layout file so that MDX files can use them without imports, and this is where the error is occurring.
During
astro:build:setup, the@astrojs/dbintegration callsgetTempViteServer()to create a temporary Vite server for seed file execution. This temp server shares the same plugin objects as the main build, and callingcreateServer()triggersconfigureServeron all of them — includingastro:content-asset-propagation, which stores adevModuleLoaderreference.Later, during the main build's transform phase, the
content-asset-propagationplugin checksif (devModuleLoader)and, finding it set, tries to evaluate MDX modules standalone viadevModuleLoader.import(basePath). The temp server was created withssr: { external: [] } (nothing externalized), so this evaluation hits a circular dependency betweenastro/dist/runtime/server/index.jsandjsx.js. The circular import causes a const binding (Renderer2, aliased as__vite_ssr_import_8__) to be in the Temporal Dead Zone when__astro_tag_component__tries to use it.The
devModuleLoadercode path is only meant for the dev server — during build it should use the placeholder strategy instead, where placeholders are later replaced with actual CSS/JS byastroConfigBuildPluginin post-build.What's the expected result?
The build should complete successfully. The
devModuleLoadershould not be set (or should not be used) during build mode.My Setup (Reproduction Context)
MDX files in my project don't import components directly. Instead, we have a MarkdownLayout.astro layout that imports ~16 components and passes them to the rendered content.
The
@astrojs/mdxpostprocess plugin injects__astro_tag_component__calls into the compiled MDX for each of these component usages. When the contaminateddevModuleLoaderevaluates these MDX modules standalone during build, the__astro_tag_component__import fromastro/runtime/server/index.jstriggers the circular dependency crash.The bug is non-deterministic — it depends on module evaluation order during parallel processing. Some builds pass, others fail on different MDX files.
Workaround
I added a Vite plugin that wraps the
content-asset-propagationplugin's transform during build to forceoptions.ssr = false, which skips thedevModuleLoadercode path:https://gist.github.com/webstackdev/4b20b42dd91b9698a942e61fcd357132
Related Issues:
#13085
#13152
Link to Minimal Reproducible Example
https://gist.github.com/webstackdev/4b20b42dd91b9698a942e61fcd357132
Participation