Emit for dynamic import (import()) when target >= ES2020 and module == None

[rbuckton]

Bug Report

We unconditionally transform dynamic import (import()) regardless of the current script target when the module kind is None. This is due to us using the CommonJS module emit as a fallback for None, and is causing an issue for VSCode while trying to implement support for TS Server plugins on the web via WebWorker.

I propose that we change the emit behavior for import() when the module target is None to preserve import(). Note that this would constitute a breaking change, but I imagine the number of affected projects (those currently using both --module None and import()) would be vanishingly small.

🔎 Search Terms

dynamic import module none node transform emit outFile

⏯ Playground Link

Playground link with relevant code

💻 Code

// @target: es2020
// @module: none
// @outFile: foo.js
const foo = import("foo");

🙁 Actual behavior

Transforms import() into a call to require()

🙂 Expected behavior

Does not transform import().

[rbuckton]

/cc: @DanielRosenwasser, @RyanCavanaugh

[craigphicks]

@rbuckton

    export enum ModuleKind {
        None = 0,
        CommonJS = 1,
        AMD = 2,
        UMD = 3,
        System = 4,
        ES2015 = 5,
        ES2020 = 6,
        ESNext = 99
    }

According to https://www.typescriptlang.org/tsconfig#module, the default value is
CommonJS if target is ES3 or ES5, otherwise it is ES6/ES2015.

When you say "... This is due to us using the CommonJS module emit as a fallback for None", what does that mean exactly?
Do you actually set the value to "None" in the tsconfig.json text file?
Or set an internal tsconfig memory object member "module" to ts.ModuleKind.None inside a custom API?

In case of simple running tsc, an missing "module" property in tsconfig.compilerOptions should result in the correct default value internally (not always "CommonJS"). I can see how that might not happen if you are using a custom API. If the correct default is not happening when it should I guess it would be a bug. But the API allows overriding that default value intentionally, or even not intentionally.

[haydentech]

Will the fix for this issue include the unconditional suppression of "export {};" from the end of the emitted JavaScript when module is set to None?

[RyanCavanaugh]

@haydentech that isn't related to this issue