Why does module.importInterop=node disable _interop_require_default

[jfirebaugh]

I have a TS package (call it ts_package) that consumes a CJS package (call it cjs_with_interop) that uses __esModule-based interop to indicate its default export. I want to use SWC to transpile ts_package to CJS with the interop necessary for downstream ESM packages to consume ts_package's transpiled output as if it had ESM named exports -- i.e., the transpiled output needs to be compatible with cjs-module-lexer. I have seen that the suggested way to do this is to set module.importInterop=node. But this disables the _interop_require_default that allows ts_package to correctly import from cjs_with_interop! Why does it do that? How do I get swc to emit CJS that simultaneously supports both __esModule interop for its imports and cjs-module-lexer interop for its exports?

Here's a minimal repro.

[kdy1]

https://swc.rs/docs/configuration/modules#importinterop
Use swc

[jfirebaugh]

That doesn't work. As the documentation states, swc is the default, so the result is the same as not setting importInterop: the transpiled output is not compatible with cjs-module-lexer and node gives a SyntaxError.

[jfirebaugh]

I've updated the README.md in my minimal repro to show that this suggested answer does not work.

[magic-akari]

Use exportInteropAnnotation.
Note: this is an undocumented API and may change in the future.

[jfirebaugh]

So, there's currently no way to accomplish this with a public API, correct?

[magic-akari]

Next.js is currently using it. See #7330.

These requirements typically suggest a complex user runtime environment.
cjs-module-lexer indicates that the file should be imported with Node ESM, but importinterop for SWC (Babel) suggests the need for a transpiler to handle require instead of relying on Node's interoperability features.

Therefore, because of varying import and export styles, we frequently assume there's an issue. If you believe the current state to be acceptable, you can utilize the exportInteropAnnotation option.

[jfirebaugh]

I don't think the requirements are that uncommon:

• I want to author a package as TypeScript and publish it as CJS
• I want it to be consumable from Node ESM as if it has named exports
• It has a dependency on a package that publishes as CJS with __esModule interop

Which of those requirements seem unusual/uncommon/complex? You're saying I have to use an undocumented, unstable API to accomplish something that seems to be like it should be supported out of the box with importInterop=node. Why not just not disable _interop_require_default under importInterop=node?

[kdy1]

importInterop=node means interop=node for imports, and common js.of node.js does not use __esModule. It's expected by the design of commonjs implementation in nodejs. __esModule is a workaround implemented by tools like babel and swc.

The problem is that the package you are trying to use is compiled using some tool with export interop mode = babel/swc, and it's using the export interop mode of babel/swc. It's not the form of a common js (which is required for importInterop=node) module expected for node.js. It's for babel, swc, tsc, etc... So you are expected to consume it via a tool that supports __esModule.

[jfirebaugh]

I think __esModule-based interop in packages published to npm is much, much more common than you imply. Virtually every package that is authored in TypeScript and transpiled to CJS with tsc is going to be using __esModule.

[kdy1]

I’m not talking about how common it is. I’m describing the rationale behind the behavior.

[jfirebaugh]

Thank you for continuing to engage. I would like to understand the rationale. So far it doesn't make sense to me.

esbuild handles this as I would expect:

$ cat ts_package.ts | npx esbuild --loader=ts --format=cjs --platform=node > ts_package.cjs
$ node esm_consumer.mjs                                                                          
ts_package.cjs default
esm_consumer.mjs default

So does tsc:

$ npx tsc ts_package.ts --module commonjs && mv ts_package.js ts_package.cjs 
$ node esm_consumer.mjs 
ts_package.cjs default
esm_consumer.mjs default

Maybe it would help to be more concrete about the issues this causes?

import Semaphore from 'semaphore-async-await'
const semaphore = new Semaphore(1)
export const a = "a"
export const b= "b"

Transpiling that with swc -C importInterop=node produces an output that fails at runtime with TypeError: _semaphoreasyncawait is not a constructor. Transpiling it with swc -C importInterop=swc produces an output where the named exports can't be imported from ESM.

Another example of why I find this rationale so hard to comprehend is that it makes swc's output incompatible with itself. Consider:

$ cat dir/a.ts
export default "a";
$ cat dir/b.ts
import aDefault from "./a";
console.log(aDefault);
$ npx swc -C module.type=commonjs -C module.importInterop=node dir -d .
Successfully compiled: 2 files with swc (32.65ms)
$ node dir/b.js
{ default: [Getter] }

Do any of the following accurately capture the rationale for why swc won't support this?

• Very few people need to do things like this, so it's not worth the effort for swc to support. The few people that do need it can use an undocumented, unstable API.
• If you want to import from an npm package that, like semaphore-async-await, provides a default export with __esModule interop, then you should avoid transpiling to CJS with swc.
• If you want to import from an npm package that, like semaphore-async-await, provides a default export with __esModule interop, and transpile to CJS with swc, then you should avoid needing to also support interop with ESM for your named exports.

[magic-akari]

that it makes swc's output incompatible with itself

The following content is unrelated to the main topic and only addresses the issue of "SWC's output being incompatible with itself."

module .importInterop=node emulates Node's import strategy, while module.type=commonjs signifies a transition to commonjs modules.

Let's examine how Node handles this issue. We use the mjs and cjs extensions to help Node identify the module types.

// b.mjs
import aDefault from "./a.cjs";
console.log(aDefault);

This illustrates how b.mjs imports the cjs module.
Regrettably, we cannot write the equivalent syntax for export default in a.cjs without prior expectations, so we compromise.

// a.cjs
module.exports = require("./a.mjs");

We delegate this issue to Node to see how it manages interoperability between ESM and CJS.

The content of a.mjs is straightforward.

// a.mjs
export default "a";

We run it directly, noting that Node version 22 or above is required, along with the --experimental-require-module flag.

node --experimental-require-module b.mjs

What do you observe?
My test yields the following output:

[Module: null prototype] { __esModule: true, default: 'a' }