Expose resolveModuleNames

[arcanis]

Hi!

Would it be possible to consider exposing the resolveModuleNames function (set in servicesHost.ts) through a configuration settings?

I'm currently experimenting integrating Yarn PnP with TypeScript through ts-loader, and my initial results are very promising. I think I could get something working just by going through this hook, which would unlock pretty interesting options!

[thatsmydoing]

I would be somewhat interested in something like this as well for a different reason. We found that for our project ts-loader was spending more than a third of it's time resolving module names. It's slow because in the current implementation, names are resolved twice, and the results are not cached.

The default typescript resolver caches things by default. I tried removing the custom resolveModuleNames implementation and things compiled fine and much faster. This is just anecdotal of course, but I think putting it behind a flag, or making it customizable as OP is suggesting is a good idea.

[johnnyreilly]

Go for it @arcanis! Experiment on!

[arcanis]

Will aim to set up a PR in the next week or so 👍

[johnnyreilly]

Cool - look forward to it. If tests cause you problems (many people bump on this) then stick up the PR and we can collaborate

[johnnyreilly]

It's slow because in the current implementation, names are resolved twice, and the results are not cached.

By the way, did you know about this option recently added to ts-loader which adds caching? I'm planning to turn it on by default (currently off) as I've had no reports of issues:

https://github.com/TypeStrong/ts-loader/blob/master/README.md#experimentalfilecaching-boolean-defaultfalse

[arcanis]

Opened a PR at #862 with an initial implementation! 🙂

[thatsmydoing]

By the way, did you know about this option recently added to ts-loader which adds caching? I'm planning to turn it on by default (currently off) as I've had no reports of issues:

Yeah, I've tried it but it didn't make much of an improvement for us. The caching happens too late in the process it seems. Module resolution seems to be a recursive operation and that seems to be what's taking up the time.

I took a look at the current PR and the changes are also happening at too low a level for the change I was thinking of making. I'll experiment a bit more with how the resolution could be sped up.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[arcanis]

#862 is merged, issue fixed 👍