Add a module resolution mode to get module search path from Node.js executable itself

Search Terms

node path
module path
NODE_PATH

Suggestion

TypeScript's effort to match Node.js's module resolution doesn't seem to always be accurate. Further, it can never be right if Node.js has been modified or configured in any way that does not match the emulation. It should be possible for TypeScript to locate type definitions using the actual module search path that node will be using at runtime, so that the runtime and the static type checking agree exactly on which files are used. After all, the TypeScript compilation is meant to reflect static properties of the code!

Use Cases

My organization has a monorepo-style integration build of first party modules which are available in $PREFIX/lib/node. This path is used by the node executable when processing require, but TypeScript sadly needs to be taught it through tsconfig baseUrl or similar hack. I believe this should be zero config and would fix a bunch of other similar use cases where the Node.js runtime disagrees with the TypeScript compiler.

Examples

One suggested way to set this up would be a new moduleResolution mode, alongside node and classic, which rather than emulating Node.js, actually calls Node.js itself to evaluate the actual module search path which will be used by a project. This mode could be called e.g. nodeIntrospect or something bikesheddable.

A facility to specify the command used to get the module search path could be provided for advanced usages such as running Node.js in a Docker container or other isolation mechanism. The command would merely be required to return a JSON array of paths or something.

(At this point I'm unsure if Node.js actually provides something similar to Python's sys.path for this, but if this issue is accepted in principle I could try to expose something for this in Node.js.)

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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Much appreciated! Thanks!

No source files or tests are named. Start by locating TypeScript's existing moduleResolution handling and researching how Node.js exposes the runtime module search path. Done would mean an agreed design and implementation that resolves type definitions from the actual Node.js search paths, with coverage for the proposed configuration and command variations.