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).
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.
@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.
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/[email protected]"
as a possible path resolution. However, in the case of bootstrap, the default rules could still be applied.
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.
I believe this could also solve some issues with remote/network file systems at larger organizations (e.g. #16426).
I'd be very interested in a hook here for jspm resolver support.
@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.
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 馃檪
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
Hi. I propose some solution in #28624 that allow to provide in compilerOptions custom file resolution function (from node module or file). It works fine with tsc and language server.
The current situations makes this a no-go for us to use typescript.
Even the flow functionality of allowing a regex replace to the filename would allow us to use our multi-app module resolution. customResolution would be perfect.
Any progress on this? Just had to convert a project in a monorepo to yarn-pnp to resolve a dependency problem, and because I now have no node_modules in that project, tsserver does not find any of my dependencies :(
I was thinking about it a little bit, and given sufficient metadata about the types in the codebase, you could also use this as a sort of primitive typeclass system. As an example:
type eq<a> = { equals: (x: a, y: a) => boolean }
type arrEq = <a>(a: eq<a>) => eq<a[]>
const arrEq: arrEq = a => {
const equals = (xs, ys) => all(zipWith(a.equals, xs, ys))
return { equals }
}
const strEq: eq<string> = { equals: (x, y) => x === y }
type t = eq<string[]>
const arrStr: t = require("<resolve>")
// Here we introspect over the types of things in the codebase, and
// produce a module that exports `arrEq(strEq)`
arrStr.equals(["foo", "bar"], ["foo", "bar"]) // => true
Of course, this is a rather nutty idea, and maybe not the best use case for this sort of feature, but as Jurassic Park teaches us, if you can, you should. What could go wrong?
Any move on this?
@RyanCavanaugh This could actually solve my feature request https://github.com/microsoft/TypeScript/issues/31703
I could just write custom resolution strategy plugin to address my needs.
@masaeedu may be you can attempt library of typescript-module-alias
Any move on this?
Any? 馃敘
Most helpful comment
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 馃檪