microsoft / microsoft/TypeScript
Option to use "moduleResolution": "NodeNext" with new "module" value that outputs ESM code
まだ誰も着手していません。
- 主要言語
- Go
- スター
- 111k
- フォーク
- 14.4k
- 平均マージ
- 1日 19時間
- マージ済み PR(30日)
- 117
説明
🔍 Search Terms
esm, nodenext, module, moduleResolution
✅ Viability Checklist
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
⭐ Suggestion
Right now, when setting "moduleResolution" to "NodeNext", you have to set "module" to "NodeNext"
I wish to have a new module value that is valid with moduleResolution: "NodeNext" but forces TS to output ESM code (aka import/export not require), similar to the output of "module": "ES2020".
📃 Motivating Example
I believe that TS relies on a package.json as a tool, without a way to give him direct instructions (especially when using programmatic APIs), is a problematic design.
TSC as a tool should have a way to get instructions from the user, which are stronger than the pacakge.json values.
I want to have direct control on what I tell tsc to do instead of relying on side effects (package.json).
This was like this until NodeNext, but now it's changed.
Also the module resolution and module shouldn't be so strongly coupled to each other, as they are not really related to each other.
💻 Use Cases
Background:
I'm working on a big OSS tool named Bit.
When using bit, you don't usually have package.json files, as bit generates and manages them for you.
Bit also uses TS programmatically to compile files.
Once I'm setting tsconfig to have:
"compilerOptions": {
"moduleResolution": "NodeNext",
"module": "NodeNext"
},
tsc is looking for a package.json and can't find one, so it will emit CJS output for .ts files.
I was able to overcome it by manipulating the filenameI gave to ts compiler when calling its API
See calling to ts transpile module APi [here](https://bit.cloud/teambit/typescript/typescript-compiler/~code/typescript-compiler.ts#l108)
And the manipulation of the filename [here](https://bit.cloud/teambit/typescript/typescript-compiler/~code/typescript-compiler.ts#l206)
This works just fine when compiling the code.
(I saw other tools using this method like thets-jest useESM` option. and others)
However, this introduces 2 issues:
- This is a very hacky way to do it, when I just want to "force" ts to compile to ESM (similar to
"module": "ES2020") and not based on package.json. - This works fine on compilation, but the IDE for example is not aware for this, which leads to errors such as
The 'import.meta' meta-property is not allowed in files which will build into CommonJS output.ts(1470)
The IDE thinks (correctly from his point of view), that the file will be compiled to CJS, but it's not true.
But I have no way to tell him that it will be compiled to ESM in action.
Right now, my other option is to set tsconfig to have:
"compilerOptions": {
"moduleResolution": "Node",
"module": "ES2020"
},
But this leads to another issue with module resolution.
I believe this resolution issue, is a bug. I have an easy (for me) way to reproduce that resolution issue, but unfortunately, I don't know how to easily reproduce it for someone else, as it requires installing bit and doing some bit actions. it's somehow related to symlinks in the node_modules and so. (I would be glad to show this in a live session and instruct someone how to reproduce it on his machine if he is willing to install bit).
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、Bit の typescript-compiler.ts からリンクされている TypeScript compiler API の使用方法とファイル名操作を読み、その後、moduleResolution: "NodeNext" と module: "NodeNext" がどのように出力を決定するかを追ってください。完全な解決策では、NodeNext の解決を維持しながら ESM 出力を強制する module オプションを提供し、IDE とコンパイラーがその出力に合意できるようにします。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- nodejs, typescript
- 領域
- compilers
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100