CJS named imports in an ESM library

[mkilpatrick]

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

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.

Reproduction

N/A

Steps to reproduce

No response

System Info

System:
    OS: macOS 12.6
    CPU: (10) arm64 Apple M1 Max
    Memory: 121.53 MB / 64.00 GB
    Shell: 5.2.15 - /usr/local/bin/bash
  Binaries:
    Node: 18.9.0 - ~/.nvm/versions/node/v18.9.0/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.4.1 - /opt/homebrew/bin/npm
    pnpm: 8.6.2 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 116.0.5845.179
    Safari: 16.4.1
  npmPackages:
    @vitejs/plugin-legacy: ^4.1.1 => 4.1.1 
    @vitejs/plugin-react: ^4.0.3 => 4.0.4 
    vite: ^4.4.9 => 4.4.9

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• 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.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[mkilpatrick]

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 😢

[bluwy]

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.