Proposal: modify cli to nudge People to do the right thing in nodejs 19.1+

[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.

• Fyko/node@4ce3b04

Suggestion

🔍 Search Terms

ESM, moduleResolution

✅ Viability Checklist

My suggestion meets these guidelines:

• 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 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.

• esm: add --import flag nodejs/node#43942

closes:

• esm: add --import flag nodejs/node#43942
• A Proposal For Module Resolution #50152
• Native support for PnP #35206
• Solutions for Editing Issues with JSDoc in TypeScript Files #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
• Support package.json exports outside of Node #50794
• NodeNext resolution failed to resolve dual-package correctly #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.

[DanielRosenwasser]

This wouldn't be a breaking change in existing TypeScript/JavaScript code

It is definitely a breaking change to remove options or change them silently depending on the underlying runtime. It would also make for a more confusing experience when a user updates their CI or local Node version without realizing that TypeScript will treat their machine differently.

[lemanschik]

@DanielRosenwasser ok fair but my current view is they are already broken as there is nothing really working besides hardcoded workarounds like ambient modules by blomberg which would keep working i did a small matrix there would not brake much as you already broke everything via nodeX resolve the basic node resolve + classic maybe would be soft enough that no one even

gets a effect other then something works that did not work before. if he is not starting from scratch. But your right we can inject that also on package levels and simply throw out eslint and babel and other ecosystem packages

that then know that they are running in typescript + nodejs19

But ok my main job is done your now aware of the fact that typescript loaders now exist and a new plugin system for the resolvers also we can now do chains

node -i @rollup/loader -i typescript typescript/tslib.js 

[fatcerberus]

I have no clue what you’re even trying to say.

[lemanschik]

@fatcerberus maybe this gives you a bit more understand able background then the highlevel above

• PR: Incremental refactoring to web-modules vscode#167505