Repository navigation
Expose configuration hook for custom module resolution #18896
Description
Activity
Note that this is already an option for non-
tscenvironments because thehostobject given to the compiler exposesresolveModuleNameswhich 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.
Ryan Cavanaugh (@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
pathsin 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.
Reacted by Aluan Haddad, Josh McDonald, Jessica Franco, Wojciech Wierchoła, Hampus Ahlgren, Nicky McCurdy, cimak, Sean M. Vieira, Chris Cowan, Tomasz Gawel and 2 moreReacted by Tomasz Gawel and roelentlessI 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.
Reacted by Aluan HaddadI believe this could also solve some issues with remote/network file systems at larger organizations (e.g. #16426).
Reacted by Aluan HaddadI'd be very interested in a hook here for jspm resolver support.
Reacted by Aluan Haddad, Jessica Franco and Bnaya PeretzAsad Saeeduddin (@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 🙂
Reacted by Gaëtan Maisse, Eugene Lubarsky, Haroen Viaene, Fiona Hopkins, Rich Adams, Max, Joel Jeske, ivan, Hampus Ahlgren, Julian Dominguez and 17 moreWould a new "moduleResolution" option make sense for this? Maybe something like
yarnpnp? I'd like to have the basictsctoolchain work yarn plug-n-playHi. 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.
Reacted by Hampus Ahlgren and Nick PorterThe 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.Reacted by Michał Skowronek and walkerburginAny 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 :(
Reacted by Gabor Babicz, Michel Rasschaert, Naor Ami, Huy Nguyen, Biel Simon Rojas, Michał Skowronek, Kuznetsov Dmitriy, Tomasz Gawel, Anton Kropp, Jo and 1 moreI 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?
Reacted by Sean M. VieiraAny move on this?
Reacted by Tomasz Gawel, Jo and Piotr StaniówRyan Cavanaugh (@RyanCavanaugh) This could actually solve my feature request #31703
I could just write custom resolution strategy plugin to address my needs.Asad Saeeduddin (@masaeedu) may be you can attempt library of typescript-module-alias
Reacted by Tomasz Gawel and kishiiAny move on this?
Any? 🔢
It would be really great to have this on TS. Webpack and Babel both support writing custom resolvers. ESLint also has, through eslint-plugin-import.
There's a similar issue with some good insights on its usefulness: typescript-eslint/typescript-eslint#2771 (I actually think it should've been here as it's not typescript-eslint job to solve this but tsc).
Year 2021, still looking forward on this.
This document https://www.typescriptlang.org/docs/handbook/module-resolution.html#module-resolution-strategies now is some complex, why not just give a hook function for user to do the resolve.
Reacted by Tomasz Gawel, Alexey Cherepanov, Nick Porter, lamo2k123, Andrey Tsapko, ixlei, arontsang, Josh, Piotr Staniów, Damian Pieczynski and 5 moreWould it be the ideal solution for nodejs to stabilize the loaders api, given that typescript's module resolution mimics node's module resolution algorithm?
This would allow to type check one project by types from others, for example i have a
common-uipackage that has a peerDependencies for react17 and 18, and devDependencies is set to react18.I would like to import it in
app17and typecheckcommon-uiwith react17, now it's not possible as the node resolution kiks in and picks types fromcommon-uinode_modules.Reacted by Hamid Shoja, David House, Yoav Balasiano and andrew-rhombus
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
pathsandbaseUrlconfiguration 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
tsconfigoption 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 theirtsconfig.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
Systemfrom here, which could open up more interesting use cases (e.g. "virtual" modules built using code generation, or F# style type providers).