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 se nombran archivos fuente ni pruebas. Empieza por localizar el manejo existente de moduleResolution en TypeScript e investigar cómo Node.js expone la ruta de búsqueda de módulos en tiempo de ejecución. Se considerará terminado cuando haya un diseño y una implementación acordados que resuelvan las definiciones de tipos a partir de las rutas de búsqueda reales de Node.js, con cobertura para las variaciones propuestas de configuración y comandos.