SWC TypeScript transpiling is moving imports to the top of the file

[joshden]

I am looking into moving our transpiling with ts-node to use SWC instead of the default in order to have much better performance. I found a difference though with SWC that is breaking our current code base.

Given these two TypeScript files:

// a.ts
console.log('a!')
import { b } from 'b'
console.log(b)

// b.ts
console.log('b!')
export const b = { b: 1 }

TSC

When I run npx tsc, I get this output (as expected):

// a.js
console.log('a!');
import { b } from 'b';
console.log(b);

// b.js
console.log('b!');
export const b = { b: 1 };

SWC

However, when I run npx swc a.ts b.ts -d swc-output, I get this output:

// a.js
import { b } from 'b';
console.log('a!');
console.log(b);

// b.js
console.log('b!');
export var b = {
    b: 1
};

Notice how with SWC, in the a.js file, the import line and first console.log line are swapped. It seems to be transpiling so all the imports are done before any of the code in the module is run. I have a case where I run some code before the first import to setup some global state. I realize this code isn't very clean in its present form, but I was surprised to see SWC move the import to the top as compared to TSC. Is this expected?

[kwonoj]

Which module output target you're aiming, esm as is (preserving import) or using other targets like cjs?

afaik, this shouldn't matter if it's for esm since esm spec specifies any import evalution should be completed before code (https://hacks.mozilla.org/2015/08/es6-in-depth-modules/) so even placing statement before import syntax, it won't run before import completes. tsc leaves as-is since syntaxwise it's not prevented (microsoft/TypeScript#16166 (comment)) but import is always hoisted, while babel seems to do explicit hoisting babel/babel#1057. I can't comment with gaurantee, but looks like swc follows babel's model.

Answer may different for the q have a case where I run some code before the first import to setup some global state depends on what output module target you're specifying probabaly. cjs could use require, or esm can use dynamic import().

[joshden]

Thank you, @kwonoj, for your reply. I've been using tsc with a target module system of commonjs.

I see what you mean with esm import evaluation being completed before code. Thank you for giving the links. I tried running with esm in Node.js 14, with the code before the import, and I do see that the import is being hoisted, so looks like swc is consistent in moving it to the top.

I think I probably need to just rework my code which will make it cleaner and support both cjs and esm which will be more forward-compatible and work with swc. Thank you for your help.