Proposal: switch moduleResolution implementation for cli if running in NodeJS 19.1 + drop typescript moduleResolution Support complete in cli

[lemanschik]

Preamble as docs are just getting done

--import=module

Preload the specified module at startup.

Follows [ECMAScript module][] resolution rules. Use [--require][] to load a [CommonJS module][]. Modules preloaded with --require will run before modules preloaded with --import.

• [ ] https://github.com/Fyko/node/commit/4ce3b04a28b0b23d8121d38218db26da70ae0349

Suggestion

🔍 Search Terms

ESM, moduleResolution

✅ Viability Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

detect if running in nodejs 19.1 if so drop moduleResolution support complete only keep classic and use require import respectively also inform the user that he should use customModule Resolution loaders via --import and require flags of nodejs 19.1 as 19.1 and onging will not get LTS that is total fine if he runs on such a environment he wants the feature else he would go for LTS.

He can then implement a function that he uses via --require[] --import[] before frozzen intrensics to offer custom module resolution based on what he needs also the resolution is shareAble via IPC or any guess able other Interfaces that a ECMAScript context supplys at present this are implemented as pre started workers

• offer a fallback loader for people that want to keep the old typescript config driven module resolution but let them explicitly set that as flag this is cli only so the programmatic version can stay as is to get refactored into modules.
• offer a lot of docs and modules to interact with the ecosystem like modular implementations that can get reused in tsserver. prepare for more worker ipc loaders via new ReadableStream and WriteableStream (Yes the web stream methods) they are supported in nodejs 19.1 and the other contexts. and lead to the smallest amount of code that handels most of the dispatching logic and chain propagation out of the box so do not code own implementations.

📃 Motivating Example

endless reuseable usecases cross ecosystem drops moduleResolution from typescript scope makes typescript a consumer of a resolver that is context indipedent and agnostic.

so this would nudge Module Authors and make them aware of a solution that solves a lot of his problems at the root cause.

• https://github.com/nodejs/node/pull/43942

closes:

• [ ] https://github.com/nodejs/node/pull/43942
• [ ] https://github.com/microsoft/TypeScript/issues/50152
• [ ] https://github.com/microsoft/TypeScript/pull/35206
• [ ] https://github.com/microsoft/TypeScript/issues/51104
  • closed via simply supporting proposal type annotations finally leave rest for intrensics
    • the new ts-loader.cjs and ts-loader.mjs support directly proposal type annotations for ECMAScript files .js .mjs .cjs
• [ ] https://github.com/microsoft/TypeScript/issues/50794
• [ ] https://github.com/microsoft/TypeScript/issues/50466

💻 Use Cases

• [ ] endless reuseable usecases cross ecosystem drops moduleResolution from typescript scope makes typescript a consumer of a resolver that is context indipedent and agnostic.
• [ ] Export typescript moduleResolution into a external file and use it as sharedLoader cross context.
• [ ] allows to get directly used including type declarations inside vscode. in fact the same extension can share the same moduleResolution including the addition of meta

• [ ] create a external load able indipendent typescript-resolver module that works in a worker like environment.