typescript-go icon indicating copy to clipboard operation
typescript-go copied to clipboard

TS1323: Dynamic imports are not supported when targeting `"module": "None"`

Open HolgerJeromin opened this issue 3 weeks ago • 3 comments

Steps to reproduce

https://github.com/HolgerJeromin/reproducible-examples/tree/tsgo-2215-dyn-import

I have a module file with exports.

// file: src/main.ts
export const appVersion = "1.0.0";
tsconfig.json
{
  "$schema": "http://json.schemastore.org/tsconfig",
  "compilerOptions": {
    "composite": true,
    "module": "es2022",
    "target": "ES2022",
    "types": [],

    "strict": true
  },
  "files": ["main.ts"]
} 

Furthermore I have a non-module ("module": "None") project which imports this code.

// file: nonmodule/nonmodule.ts
import("../src/main.js").then((module) => {
  console.log(module.appVersion);
});
tsconfig.json
{
  "$schema": "http://json.schemastore.org/tsconfig",  
  "references": [{"path": "../src"}],
  "compilerOptions": {
    "composite": true,
    "module": "None",
    "target": "ES2022",
    "types": [],

    "strict": true
  },
  "files": ["nonmodule.ts"]
}

This is needed to combine both worlds.

Behavior with [email protected]

Compiles without problems.

Behavior with tsgo

nonmodule/nonmodule.ts:1:1 - error TS1323: Dynamic imports are only supported when the '--module' flag is set to 'es2020', 'es2022', 'esnext', 'commonjs', 'amd', 'system', 'umd', 'node16', 'node18', 'node20', or 'nodenext'.

1 import("../src/main.js").then((module) => {
  ~~~~~~~~~~~~~~~~~~~~~~~~


Found 1 error in nonmodule/nonmodule.ts:1

HolgerJeromin avatar Dec 04 '25 12:12 HolgerJeromin

See also https://github.com/microsoft/typescript-go/issues/2214#issuecomment-3612585349

jakebailey avatar Dec 04 '25 14:12 jakebailey

I don't quite understand "module none" yet using imports. Why not another mode?

jakebailey avatar Dec 04 '25 14:12 jakebailey

I don't quite understand "module none" yet using imports. Why not another mode?

We migrate our code to modules while keeping backwards compatibility.

Some parts are still non-module code but consumes already migrated parts of the application. So dynamic imports are a perfect fit.

Also our test infrastructure is all non-module because we want to test test the non-module customer code but also want to test module code (but did not want to split the unit test project right now in two parts).

But the same here:

-    "module": "None",
+    "moduleDetection": "legacy",

does not fix compile of the sample.

HolgerJeromin avatar Dec 04 '25 16:12 HolgerJeromin