swc compatibility issues

[alexeagle]

SWC is a VERY fast transpiler, allowing TypeScript to be converted to JavaScript in milliseconds and at large scale.

This discussion can collect pointers to the problems we know of when using ts_project(transpiler = swc) along with known workarounds.

[alexeagle]

@matthewjh points out two issues:

1. Where SWC can't figure out based on local information whether an import of a symbol should be a "type import" and not emitted, users need to use type-only imports (and exports). Two example situations where this arises most prominently are emitDecoratorMetadata (which introduces ambiguity as symbols in type positions can be "promoted" to value symbols) and files without any usage information like:

export {A, B} from "./index";
// is A going to exist at runtime?
// is B?

This is "breaking" because if SWC emits an import for a symbol that doesn't exist in the corresponding file, that will break downstream in bundling or loading the module via Node.

3. Consuming const enums from NPM packages doesn't really work in SWC. The const enum doesn't exist at runtime, and SWC doesn't have the information to inline the value as TSC does. Some libraries export const enums.

#289 (comment)

[jbedard]

ESM transpiled to CommonJS:

When transpiling esm to cjs SWC tries to maintain the esm behaviour and restrictions, while tsc transpiles to a more lenient version more closely aligned with node cjs.

For example, esm imports are readonly and can not be modified, traditionally cjs imports are writeable (the exports object).

Source ts:

export const FOO = "bar"

SWC output:

Object.defineProperty(exports, "FOO", {
    enumerable: true,
    get: function() {
        return FOO;
    }
});
var FOO = "bar"

TypeScript output:

exports.FOO = void 0;
var FOO = "bar"
exports.FOO = FOO;