MDC component fails to import parseMarkdown function
The MDC component is not rendering anything.
I managed to get the following error:
Failed to import parseMarkdown SyntaxError: The requested module '/_nuxt/@fs/Users/.../node_modules/.pnpm/extend@3.0.2/node_modules/extend/index.js?v=c60aeab6' does not provide an export named 'default'
It was quite annoying to get this information because the import silently fails inside the useAsyncData composable.
Is Nuxt/Vite optimizing this away because of the dynamic import?
edit:
when I look at the actual file I can find this:
module.exports = function extend() {
// implementation
}
But this package hasn't been updated for years so I'm unsure what is going on here
edit 2:
Seems like an issue in @rollup/plugin-commonjs in vite. It is supposed to be fixed in the latest version but I'm still having this issue. Looking into it further...
edit 3:
Possible cause: rollup/plugins#1924
5 Replies
Hi @Mateleo. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
The error you're encountering:
is a classic interoperability issue between CommonJS (CJS) and ES Modules (ESM). The
When importing a CJS module in ESM, you may need to access the
You can add the problematic library to
Nuxt internally uses the
This is a known issue when mixing CJS and ESM, especially with dynamic imports and older packages. The recommended workaround is to manually interop the default export or configure Nuxt to transpile or alias the package. The root cause is not Nuxt/Vite "optimizing away" the import, but rather the limitations of CJS/ESM interop in the current toolchain [Troubleshooting ESM Issues]. If the issue persists even after these workarounds, it may be due to an unresolved bug in the underlying Rollup or Vite plugins, as you referenced in your research and as Nuxt has addressed in some recent fixes [fix(vite): use arrow functions in dynamic imports]. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
extend package you referenced uses CJS syntax (module.exports = function extend() { ... }), but your code (or a dependency) is trying to import it as if it had a default ESM export.
Why does this happen?
- When you use import extend from 'extend' in ESM, Node.js and Vite expect extend to have a default export, but CJS modules export via module.exports, not export default.
- Bundlers like Vite (which uses Rollup under the hood) try to interop CJS and ESM, but this can fail, especially with dynamic imports or if the CJS/ESM boundary isn't handled correctly by plugins like @rollup/plugin-commonjs or Vite's own CJS handling.
Is Vite optimizing this away because of the dynamic import?
- Not exactly "optimizing away," but dynamic imports can complicate how CJS modules are transformed and loaded, especially if the plugin responsible for CJS interop doesn't handle the case correctly. There are known issues in Rollup and its plugins regarding dynamic imports and CJS interop, as you noted in your edits and as referenced in upstream issues and Nuxt's own changelogs [fix(vite): use arrow functions in dynamic imports].
How to fix or work around this:
1. Manually interop the default export:When importing a CJS module in ESM, you may need to access the
.default property or use a helper. For dynamic imports, you can do:
Or, for static imports:
Nuxt recommends this approach for such cases [Troubleshooting ESM Issues].
2. Transpile or alias the library:You can add the problematic library to
build.transpile in your nuxt.config to ensure it's processed correctly:
Or, alias it to a CJS entry if available:
3. Use mlly for safer interop:Nuxt internally uses the
mlly package to handle these interop cases more robustly. You can use it as well:
Summary:This is a known issue when mixing CJS and ESM, especially with dynamic imports and older packages. The recommended workaround is to manually interop the default export or configure Nuxt to transpile or alias the package. The root cause is not Nuxt/Vite "optimizing away" the import, but rather the limitations of CJS/ESM interop in the current toolchain [Troubleshooting ESM Issues]. If the issue persists even after these workarounds, it may be due to an unresolved bug in the underlying Rollup or Vite plugins, as you referenced in your research and as Nuxt has addressed in some recent fixes [fix(vite): use arrow functions in dynamic imports]. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@142772824556306433> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
Uncaught (in promise) SyntaxError: The requested module '/_nuxt/@fs/C:/Informatique/ALICEv2/node_modules/.pnpm/extend@3.0.2/node_modules/extend/index.js?v=ff824eca' does not provide an export named 'default' (at index.js?v=ff824eca:350:8)
Nope still the same issue @kapa.ai
build: {
transpile: ["extend"],
},
Let me check the knowledge base for you again. One moment! :books:
----------------------
The error message:
indicates that the
If you are dynamically importing
In some cases, you may need to alias the library to its CJS entry point: This can help Nuxt/Vite resolve the correct file format [Troubleshooting ESM Issues]. 3. Upstream Issue
If these workarounds do not resolve the issue, it may be due to a limitation or bug in the Vite/Rollup CommonJS interop, as noted in your research and in the Nuxt documentation. In such cases, the issue is with the upstream library or the build toolchain, and a permanent fix may require changes in those tools or the library itself [Troubleshooting ESM Issues]. Summary:
Transpiling alone may not be enough for some CommonJS modules. Manual interop or aliasing is often required. If the problem persists, it is likely due to limitations in the current ESM/CJS interop in the build tools, and not something Nuxt can fully resolve on its own. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
extend package is a CommonJS module, but your code (or a dependency) is trying to import it as if it were an ES module with a default export. Adding extend to build.transpile in your nuxt.config is a recommended step, but it may not always resolve the issue if the underlying import style is incompatible [Troubleshooting ESM Issues].
What you can try next:
1. Manually Interop the Default ExportIf you are dynamically importing
extend, use:
For static imports, try:
This approach is recommended in the Nuxt documentation for handling CJS/ESM interop issues [Troubleshooting ESM Issues].
2. Aliasing the LibraryIn some cases, you may need to alias the library to its CJS entry point: This can help Nuxt/Vite resolve the correct file format [Troubleshooting ESM Issues]. 3. Upstream Issue
If these workarounds do not resolve the issue, it may be due to a limitation or bug in the Vite/Rollup CommonJS interop, as noted in your research and in the Nuxt documentation. In such cases, the issue is with the upstream library or the build toolchain, and a permanent fix may require changes in those tools or the library itself [Troubleshooting ESM Issues]. Summary:
Transpiling alone may not be enough for some CommonJS modules. Manual interop or aliasing is often required. If the problem persists, it is likely due to limitations in the current ESM/CJS interop in the build tools, and not something Nuxt can fully resolve on its own. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@142772824556306433> Kapa.ai is still learning and improving, please let me know how I did by reacting below.