Option to use "moduleResolution": "NodeNext" with new "module" value that outputs ESM code

🔍 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:

1. 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.
2. 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).

Empieza leyendo el uso de la API del compilador de TypeScript y la manipulación de nombres de archivo enlazada desde el typescript-compiler.ts de Bit; después, sigue cómo moduleResolution: "NodeNext" y module: "NodeNext" determinan la salida. Una solución completa proporcionaría una opción module que preserve la resolución NodeNext y fuerce la salida ESM, haciendo que el IDE y el compilador coincidan en esa salida.