dynamic import from module=none of an module=es2022 via barrel reemits it as commonjs

[HolgerJeromin]

🔎 Search Terms

module import commonjs barrel

🕗 Version & Regression Information

• This is the behavior in every version I tried. Tried 3.3, 5.7.3 and 5.9-nightly.

⏯ Playground Link

https://github.com/HolgerJeromin/reproducible-examples/tree/ts-61316

💻 Code

Folder jsModule with tsconfig and one module file and a barrel file:

file jsModule/jsModule.ts

 export class TreeView {
  constructor() {}
}

file jsModule/services.ts

export {TreeView} from "./jsModule.js"

jsModule/tsconfig.json

{
  "compilerOptions": {
    "composite": true,
    "module": "ESNext",
    "target": "ESNext", 
    "strict": true
  },
  "files": ["jsModule.ts", "services.ts"]
}

And a folder src with module=none compile:

file src/main.ts

// both of these two imports trigger the bug:
type TreeView = import("../jsModule/services.js").TreeView;
import("../jsModule/services.js").then((module) => {
  const _TreeView = module.TreeView;
});

src/tsconfig.json

{
  "compilerOptions": {
    "module": "None",
    "target": "ESNext",
    "types": [],
    "strict": true
  },
  "files": ["main.ts"]
}

🙁 Actual behavior

Build jsModule folder:

.\node_modules\.bin\tsc.cmd --build  .\jsModule\ --verbose --force

Results in correct jsModule/jsModule.js

export class TreeView {
    constructor() { }
}

Build src folder:

.\node_modules\.bin\tsc.cmd --build  .\src\ --verbose --force

Changes existing jsModule/jsModule.js to commonJs output:

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.TreeView = void 0;
class TreeView {
    constructor() { }
}
exports.TreeView = TreeView;

--explainFiles shows this:

...
jsModule/jsModule.ts
  Imported via "./jsModule.js" from file 'jsModule/services.ts'
jsModule/services.ts
  Imported via "../jsModule/services.js" from file 'src/main.ts'
  Imported via "../jsModule/services.js" from file 'src/main.ts'
src/main.ts
  Part of 'files' list in tsconfig.json

🙂 Expected behavior

The emit of commonJs is completely surprising.
Expected would be one of

• The files are not included (or referenced) in src/tsconfig.json so they should not be rebuild (but only .d.ts files consumed) or
• if this needs to be rebuild it should be correctly based on its tsconfig.json

Additional information about the issue

With my real code these folders are different VS 2022 projects and therefore have no references.

[HolgerJeromin]

Friendly ping for triage as this blocks my migration to esmodules...

[jakebailey]

I'm not sure if this is a bug or not, but you probably do not want to be setting module=none (clearly, you're using modules?).

Consider trying settings suggested at: https://www.typescriptlang.org/docs/handbook/modules/guides/choosing-compiler-options.html

[HolgerJeromin]

JFYI: This is part of our browser framework. So commonJS will never work in runtime.

I'm not sure if this is a bug or not, but you probably do not want to be setting module=none (clearly, you're using modules?).

I have a module=none part (legacy code and public namespaced API) and the unit test is still module=none

While migrating parts of my application to modules I still have the core (66000 LoC output with outfile) in namespace'd module=none which dynamic import() the already migrated parts. Same in the unit test.

[HolgerJeromin]

The issue was not related to modules at all.
Opened #61440 with a more broader context