You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure that this is a bug necessarily, but more of a question if there's any workaround.
If my Vite project imports a library A that has exported both CJS/ESM (and we're using the ESM version), but the library we're importing itself is using named exports of another library B that only exports CJS, it results in errors like
SyntaxError: Named export '$applyNodeReplacement' not found. The requested module 'lexical' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:
import pkg from 'lexical';
Library A is obviously using named exports in its importing code like import {$applyNodeReplacement} from "lexical"; rather than
import pkg from 'lexical';
const {$applyNodeReplacement} = pkg;
If I import library B directly using named exports everything works fine. It's only when there's a multi-step degree of imports. Of course library A needs to be updated, but there's nothing inherently wrong with library A. It compiles and exports ESM no problem with no indication that it's importing anything incorrectly (or is there actually a way to know this?). As far as I can tell Node can't determine this statically so it only fails at runtime.
I know I can work around it in my Vite project (which is using SSR) by doing
ssr: {
noExternal: ["libA"]
},
Is there any other workaround or way to handle this, either in my own project (but for any library this could happen in without naming each one individually) or in library A by somehow catching this before it's released? I fear that many libraries have this issue and would like to avoid a whack-a-mole scenario.
Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
After further investigation I think there's nothing that can be done. vite-plugin-ssr details a lot of the same issues we've been seeing - https://vite-plugin-ssr.com/broken-npm-package
It definitely makes it hard for users to use many libraries 😢
Yeah this is definitely something out of scope of Vite. The packages are loaded through Node.js, and if the transitive Library B can't be imported by Node.js through named exports, then the only way is to have Library A fix that. As technically that means Library A's code is not Node.js compatible.
Describe the bug
I'm not sure that this is a bug necessarily, but more of a question if there's any workaround.
If my Vite project imports a library A that has exported both CJS/ESM (and we're using the ESM version), but the library we're importing itself is using named exports of another library B that only exports CJS, it results in errors like
Library A is obviously using named exports in its importing code like
import {$applyNodeReplacement} from "lexical";
rather thanIf I import library B directly using named exports everything works fine. It's only when there's a multi-step degree of imports. Of course library A needs to be updated, but there's nothing inherently wrong with library A. It compiles and exports ESM no problem with no indication that it's importing anything incorrectly (or is there actually a way to know this?). As far as I can tell Node can't determine this statically so it only fails at runtime.
I know I can work around it in my Vite project (which is using SSR) by doing
Is there any other workaround or way to handle this, either in my own project (but for any library this could happen in without naming each one individually) or in library A by somehow catching this before it's released? I fear that many libraries have this issue and would like to avoid a whack-a-mole scenario.
Reproduction
N/A
Steps to reproduce
No response
System Info
Used Package Manager
npm
Logs
No response
Validations
The text was updated successfully, but these errors were encountered: