-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when a CJS module is imported from ESM module dependencies #3024
Comments
I encountered this bug as well - a dependency (Storybook, in my case) imports core-js, and core-js uses CJS internally. |
Just FYI, But back when this was reported:
|
See this post for a (partial) workaround. |
You can try this plugin https://github.com/originjs/vite-plugins/tree/main/packages/vite-plugin-commonjs |
It seems that the main cause of this issue is that Vite skips optimizing non-JS files such as |
Also, what is this about? In the vite/packages/vite/src/node/optimizer/scan.ts Line 279 in 016b5d1
|
@benmccann I've already put some of my thoughts on it in discord, but I thought to write it out here for others. Regarding that line, what Vite's prebundling essentially does it that This also means that nested dependencies of Though I also don't think continuing the crawl is the solution (?) since it would needlessly impact pure JS libraries, and pnpm users would need to set |
Discussion notes from todays meeting:
|
When would CJS packages be prebundled? Bundling is something the app does - very few packages do. (or is “prebundling” a vite config thing) |
I assume it has something to do with this: https://vitejs.dev/guide/dep-pre-bundling.html#the-why |
Note: The repro provided uses local packages which are implicitly not optimized by default, which means the CJS module isn't optimized and leads to the error. |
And by local I think it's meant symlinked |
To rephrase the issue, I think it should be: "Error when a CJS module is imported from an unoptimized ESM dependency", since this works today if that ESM dependency is optimized, e.g. If the ESM dependency needs to be excluded from optimization, there's a pending PR #4634 that will allow the nested CJS module to be re-included back into optimization, e.g. |
According to #3024 (comment):
I think we can close this issue as intended behaviour, and also because there's now a way to optimize the nested CJS module via |
Then, what about |
I'm not sure if there's enough heuristic to have Vite suggest that error, especially since the error happens on the client side. Though I'm not too familiar with the internals to know if it's possible either. Perhaps you have some ideas where this can be handled? |
I unfortunately don't. |
@bluwy, try this please: |
There's now an experimental option to prebundle |
Closing this as this is expected behaviour as discussed above:
To fix it, optimize the ESM dependency, or the CJS dependency if the parent ESM dep is not optimizable. For example, I've looked into providing a friendlier error message, but it's not possible given the browser explicitly request it through For now this should be a rare error as vite-plugin-svelte and SvelteKit correctly handles pre-bundling now. |
Describe the bug
if a dependency that is an ES module imports a dependency that is a CJS module, the following error is encountered when running with the development server:
Uncaught SyntaxError: The requested module '/dependency2/index.js' does not provide an export named 'default'
Reproduction
Clone https://github.com/JBusillo/vanilla
do an 'npm i' and 'npm run dev'
System Info
Used package manager: npm
Additional Notes
I originally encountered this issue with the module https://github.com/IBM/carbon-components-svelte. The repro provided is simpler to demonstrate.
The problem doesn't affect the production build when using the Rollup commonjs plug-in.
One possible solution might be to do an esbuild transform within transformRequest.ts:
This transforms all .js files, even those that are already ESM, but esbuild doesn't modify the code in that case. Perhaps the transformation could be an option. Or, there could be another solution altogether.
This issue is possibly related to #2679, but that addresses UMD modules imported at the root level.
The text was updated successfully, but these errors were encountered: