Ts-loader: Expose `resolveModuleNames`

Created on 24 Oct 2018 · 9Comments · Source: TypeStrong/ts-loader

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!

wontfix

Source

arcanis

All 9 comments

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.

thatsmydoing on 25 Oct 2018

Go for it @arcanis! Experiment on!

johnnyreilly on 25 Oct 2018

👍1

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

arcanis on 25 Oct 2018

👍1

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 on 25 Oct 2018

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

johnnyreilly on 26 Oct 2018

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

arcanis on 27 Oct 2018

👍1

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.

thatsmydoing on 28 Oct 2018

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.