Expose configuration hook for custom module resolution

[masaeedu]

Following on from #6012 and #5039, it'd be nice to have the ability to add TypeScript to projects with heterogeneous module resolution/packaging systems and have typechecking work.

The paths and baseUrl configuration options get us a long way, but they don't deal well with module loaders that are less widely used, frequently changing, or that allow for complex module resolution rules. Letting the user entirely outsource all module resolution concerns using the configuration would allow type checking to work regardless of the user's preference of npm, bower, requirejs, browserify, jspm, webpack, etc.

A simple approach might be to have a tsconfig option for a parametrized command line invocation (similar to npm scripts) that is able to resolve modules. Each package manager can distribute a tool that implements module resolution according to its own needs, which the users can install and point to in their tsconfig.json.

Exactly how extensive the API needs to be is up for debate. It could be something as simple as a function that maps requested module names to file system paths, or a more abstract implementation of something like System from here, which could open up more interesting use cases (e.g. "virtual" modules built using code generation, or F# style type providers).

[RyanCavanaugh]

Note that this is already an option for non-tsc environments because the host object given to the compiler exposes resolveModuleNames which hosts may implement to their liking.

I'm not sure there's anyone who would want this ability who isn't already loading TS through some more advanced build pipeline.

[masaeedu]

@RyanCavanaugh I want to continue using VS Code as a regular editor, but also be able to use JSPM/ bower/custom webpack without doing a lot of fiddling with paths in tsconfig.

It would also be nice if I could more generally hook into the module resolution pipeline without having to implement a full language server and wrapping extension.

[aluanhaddad]

I think this could become quite flexible and workable without having too many options. Currently typescript uses a fallback strategy when resolving modules and that forgiving behavior doesn't need to change as a result of this feature.

For example, let's say I'm using moment and_bootstrap_ in my application.

I can't provide a path mapping for bootstrap because of how its declaration file references jQuery's. so maybe I have installed that declaration using npm but I have moment installed with JSPM and moment comes with its own type declaration and I that is the one I want to use and I can today just manually. so when TypeScript resolves moment, I could via this feature suggest 'jspm_packages/npm/moment@2.18.1" as a possible path resolution. However, in the case of bootstrap, the default rules could still be applied.

[davidsk]

I've also been trying to cobble together a working vscode / typescript / jspm project and eventually came to a similar conclusion as this issue describes.

My thoughts were a new compilerOption which would identify a custom resolver module that would return an array of objects, mapping containingFiles / moduleNames keys to module locations.

[
  "*": {
    "module1": "path/to/module1",
    "module2": "path/to/module2"  
  },
  "module1": {
    "module2": "different/path/to/module3"
  }
]

When should such a function be called? It could be called early on in the process and cached but if design time support is required then the map would need updated dynamically. I suspect Typescript already has a mechanism to do this.

[DanielRosenwasser]

I believe this could also solve some issues with remote/network file systems at larger organizations (e.g. #16426).

[guybedford]

I'd be very interested in a hook here for jspm resolver support.

[SupernaviX]

@masaeedu I played around a bit with modifying ts.sys to use"virtual modules"/type providers. I'd be very interested if this API was flexible enough to support virtual modules in a more general way.

[arcanis]

Just saw this issue - I'd be quite interested as well to have such a hook. Would allow me to start making experiments to integrate PnP with Typescript 🙂

[darthtrevino]

Would a new "moduleResolution" option make sense for this? Maybe something like yarnpnp? I'd like to have the basic tsc toolchain work yarn plug-n-play