Vite 8 dev pre-bundler doesn't unwrap exports.default for CJS packages

[sdbondi]

Description

Vite 8's dev server pre-bundler (oxc/rolldown) doesn't properly unwrap exports.default for CJS packages. When a CJS package sets exports.default = SomeComponent, the pre-bundled output ends with:

export default require_lib();

This returns the whole CJS module object { default: Component } instead of unwrapping to the component itself. As a result, import Foo from "cjs-package" resolves to the module wrapper object rather than the actual default export, causing runtime crashes.

Production builds (rolldown) handle this correctly - the issue is only in dev mode pre-bundling.

Reproduction

1. Install a CJS package that uses exports.default, e.g. react-qr-code or react-simple-code-editor
2. Import it with a default import: import QRCode from "react-qr-code"
3. Use it as a React component in JSX
4. Run vite dev - crashes at runtime with:

   Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.
   

5. Run vite build - works correctly

Minimum Reproduction: https://github.com/sdbondi/vite8-cjs-interop-repro

Expected behavior

import Foo from "cjs-package" should resolve to the value of exports.default in dev mode, matching the production build behavior.

Actual behavior

The import resolves to the CJS module wrapper object { default: Component, ... } instead of the unwrapped default export.

Pre-bundled output

Looking at node_modules/.vite/deps/react-qr-code.js, the tail of the file shows:

  exports.QRCode = QRCode;
  exports.default = QRCode;
}));
//#endregion
export default require_lib();

require_lib() returns the whole exports object rather than unwrapping .default.

System Info

• Vite 8.0.8
• Node 22
• Linux
• pnpm

Workaround

For packages that also have a named export (e.g. react-qr-code exports both exports.default and exports.QRCode), use the named import:

// @ts-expect-error CJS interop: Vite 8 dev pre-bundler doesn't unwrap exports.default
import { QRCode } from "react-qr-code";

For packages that only have exports.default (e.g. react-simple-code-editor), use a runtime fallback:

import EditorImport from "react-simple-code-editor";
const Editor = (EditorImport as any).default ?? EditorImport;

[github-actions]

Hello @sdbondi. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with needs reproduction will be closed if they have no activity within 3 days.

[bluwy]

Probably related https://vite.dev/guide/migration#consistent-commonjs-interop

[sdbondi]

@bluwy Ah thanks - so it looks like this point is not behaving as documented: "The module.exports.__esModule value of the importee CJS module is not set to true."

Added a repro: https://github.com/sdbondi/vite8-cjs-interop-repro

[bluwy]

It seems like the prebundling output is correct, because we don't really know who the importer is. However, we do track when some packages needsInterop, which we'd do the correct .default access dynamically.

vite/packages/vite/src/node/plugins/importAnalysis.ts

Lines 617 to 629 in 4cd0d67

	} else if (needsInterop) {
	debug?.(`${url} needs interop`)
	interopNamedImports(
	str(),
	importSpecifier,
	url,
	index,
	importer,
	isNodeMode(),
	config,
	)
	rewriteDone = true
	}

The problem seems to be here:

vite/packages/vite/src/node/plugins/importAnalysis.ts

Lines 1097 to 1103 in 4cd0d67

	if (isNodeMode) {
	lines.push(`const ${localName} = ${cjsModuleName}`)
	} else {
	lines.push(
	`const ${localName} = !${cjsModuleName}.__esModule ? ${cjsModuleName} : ${cjsModuleName}.default`,
	)
	}

In src/App.tsx, isNodeMode is true so default imports are returned as { default: ... } as expected and documented in the migration guide. So I think the bug is in build where it probably shouldn't work? I think it's all handled within rolldown so not much as can look from here.

[sdbondi]

Thanks for the detailed explanation. So if I understand correctly, because our app is type: "module", the default import correctly returns module.exports (the whole object) per the new rules, and __esModule is only considered when the importer is not in ESM/node mode.

That makes sense. So the inconsistency is that the production build (rolldown) is unwrapping .default when it shouldn't be, rather than the dev server failing to unwrap it.

For now we're using named imports where available and a runtime .default ?? import fallback for packages that only have exports.default. Is there a recommended approach for importing CJS packages that use the __esModule + exports.default pattern from an ESM app?

[sapphi-red]

It seems the same error happens in build + preview as well.
https://stackblitz.com/edit/github-238rgkuv?file=src%2Fmain.tsx,src%2FApp.tsx

Minified React error #130; visit https://react.dev/errors/130?args[]=object&args[]= for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

[bluwy]

Well duh, of course the issue is post-build runtime. My brain wasn't working right 😅 Then I guess everything is working as intended then?