Please read this if you think transpilation is wrong

[kdy1]

This document describes that are not a bug. If you file an issue that is described in this issue, the issue will be closed without any additional information.

Class fields are undefined

• Inconsistent useDefineForClassFields behavior #6985
• https://swc.rs/docs/migrating-from-tsc#usedefineforclassfields

jest.mock of ESM fails / Cannot modify ES modules.

• jest.mock of ESM should fail, and it's correct #5205

Evaluation order of module: "commonjs" is different from tsc.

The behavior of tsc is wrong. ESM is an established standard, and the specification explicitly says that ESM imports are hoisted.

• Compiler allows for using a value before it is imported microsoft/TypeScript#16166

Cyclic imports of ESM do not work (as what you want)

ESM is an established standard, and as SWC is a compiler, SWC always follows specifications.

I can't import CJS Modules from node.js ESM.

• Two named exports creates invalid CommonJS #7665 (comment)

TDZ semantics is broken

• ES5 target breaks TDZ semantics: missing ReferenceError for let access before initialization #11045 (comment)
• block_scoping: const reassignment succeeds when transpiled to ES5 #12130 (comment)
• fix(es/compat): Preserve class name TDZ in computed method keys #12390 (comment)

[karaarda]

The behavior of tsc is wrong. ESM is an established standard, and the specification explicitly says that ESM imports are hoisted.

Can you backup your claim? TypeScript claims the opposite on their official documentation. They also explicitly say that TypeScript has ESM Syntax with CommonJS behavior here.

ESM might be an established standard but it is a standard for JavaScript. TypeScript is not JavaScript.

[magic-akari]

The behavior of tsc is wrong. ESM is an established standard, and the specification explicitly says that ESM imports are hoisted.

Can you backup your claim? TypeScript claims the opposite on their official documentation. They also explicitly say that TypeScript has ESM Syntax with CommonJS behavior here.

ESM might be an established standard but it is a standard for JavaScript. TypeScript is not JavaScript.

I think some context is missing here. In this discussion, tsc refers to the compiler’s behavior when it transforms standard ESM syntax into CJS output, not to TypeScript as a language.

The related issue is here: microsoft/TypeScript#16166

The example in TypeScript’s documentation is about a TypeScript-specific top-level import syntax that corresponds to CommonJS. It is part of TypeScript’s own language design, rather than part of EcmaScript. It is also statically analyzable and can be translated to require in a 1:1 way, so it is a different topic from the behavior we are discussing above.

If you try the SWC playground, you will find that SWC also supports this TypeScript-specific syntax well.

[karaarda]

magic-akari You’re right that import x = require() the documentation is about TypeScript language design but it is also a part of TS philosophy in general.

The bigger point still stands. TS Modules – Theory page basically says it outright: the input module syntax seen in input source files is somewhat decoupled from the output module syntax emitted to JS files.

So when I set module.type: "commonjs" in .swcrc, I’m telling SWC: "my runtime is CommonJS, give me output that behaves like normal CJS." That’s what the option is for from TS handbook perspective.

I’ve tested this a lot with same TypeScript source compiled with both TSC and SWC (targeting CommonJS), plus plain JS ESM and plain JS CJS versions for comparison. Two painful differences keep showing up:

1. Circular dependencies + decorator metadata doesn't work with SWC

Think NestJS services using @Injectable() and @Inject(forwardRef(() => Something)). TSC’s output loads fine. SWC’s output throws ReferenceError: Cannot access 'X' before initialization.

The reason: SWC emits getter‑based exports that hit temporal dead zone issues, while TSC does the tricky exports.X = void 0 CJS runtimes tolerate.

Native ESM crashes the same way, which makes sense. But that’s what the module.type: "commonjs" is for based on TS handbook as I picked CommonJS as the target, CJS handles circular deps more forgivingly. SWC’s "ESM to CommonJS" output ends up giving me ESM‑style crash behavior inside a CJS wrapper, which is the worst of both worlds.

2. configurable: false on exports breaks tooling

SWC emits:

Object.defineProperty(exports, "X", {
  enumerable: true,
  get: function() { return X; }
  // configurable: false by default
});

That makes jest.spyOn(module, "X") blow up with TypeError: Cannot redefine property. This isn't an ESM correctness thing, the file is still producing a module.exports object, not an ESM namespace. There is no CJS spec that says exports must be non‑configurable. And when SWC gets actual CommonJS input (module.exports = { X }) it outputs normal, configurable properties. Same target, totally different runtime behavior just because the source syntax was ESM. Again, according to TS handbook, target host should define the output format, not the input syntax.

So with the same module.type: "commonjs" setting:

• CJS input → normal exports, circular deps work, jest spies work
• ESM input → non‑configurable getters, circular deps crash, jest spies crash

That feels backwards. The output should be controlled by the target, not the source syntax.

If SWC’s philosophy is “we want ESM‑like strictness even in CommonJS output”, fine, that’s a design choice. But then it needs to be clear that SWC is not a drop‑in replacement for TSC in existing CommonJS projects, and acknowledge these are not bugs in TSC as this decision is well documented in the TS handbook.

Right now, projects like NestJS recommend SWC as a faster alternative to TSC and developers hit these issues only after migrating. If the behavior is intentionally different, the ecosystem needs to know that upfront.

[kdy1]

If a compiler changes the behavior of the code in a way that breaks the standard, it is a bug, regardless of whether it is documented. Since ESM is the parent specification, I believe that ESM rules should apply to code using ESM syntax, regardless of what the TypeScript specification says. You used the ESM import syntax even though you could have used CJS syntax. That is why you got the ESM behavior.

[kdy1]

But I think it may worth to add something like module: tsc-commonjs given they documented that they will stick with that behavior

[magic-akari]

The conclusion is clear. We need to transition to Discussions to continue this conversation, avoiding any distraction from this issue's purpose as a pinned announcement.