resolveModuleNames doesn't get `host` & `options`

[arcanis]

TypeScript Version: master

Search Terms: resolveModuleNames resolveTypeReferenceDirectives

Actual behavior:

The resolveModuleNames hook (and its sister resolveTypeReferenceDirectives) don't get direct access to the options and resolutionHost value. It's left to the user to populate them (as shown in the documentation).

While it worked ok until now since the options are known before injecting the hook, it now causes issues with the Watch API. In this situation, the options are extracted by the internals of createWatchProgram and we don't get to access them.

We theoretically could retrieve them from watchProgram.getProgram().getCompilerOptions(), except that it requires to have the watchProgram object to begin with ... which doesn't happen until createWatchProgram returns, by which point TS will already have tried and failed the initial compilation.

Expected behavior:

The options parameter (and arguably the resolutionHost as well) should be passed as parameter to the custom resolveModuleNames and resolveTypeReferenceDirective functions. This would allow to call ts.resolveModuleName without relying on indirect sources.

Related Issues:

TypeStrong/fork-ts-checker-webpack-plugin#258 (comment)

[sheetalkamat]

Seems to me we need getCompilerOptions on WatchOfConfigFile<T> so one can get compiler options without having to get program. I don't think we should change resolveModuleNames and resolveTypeReferenceDirectives api as those are intentionally similar to CompilerHost api methods

[DanielRosenwasser]

@arcanis any interest in sending a PR? Should be relatively scoped.

[arcanis]

Seems to me we need getCompilerOptions on WatchOfConfigFile<T> so one can get compiler options without having to get program.

I don't think that would work for the same reason: we don't get access to WatchOfConfigFile<T> until after createWatchProgram returns, by which point TS will have already run (and thus failed) the initial compilation.

@arcanis any interest in sending a PR? Should be relatively scoped.

If we agree on the fix I can take a look late May unless someone beats me to it 🙂

[DanielRosenwasser]

@arcanis any interest in sending a PR? Should be relatively scoped.

[arcanis]

Seems to me we need getCompilerOptions on WatchOfConfigFile<T> so one can get compiler options without having to get program.

I don't think that would work for the same reason: we don't get access to WatchOfConfigFile<T> until after createWatchProgram returns, by which point TS will have already run (and thus failed) the initial compilation.

@arcanis any interest in sending a PR? Should be relatively scoped.

If we agree on the fix I can take a look late May unless someone beats me to it 🙂

[sheetalkamat]

I think we can add compiler options but not the resolutionHost since resolution host in case of custom module resolution is the host itself and something host would need to create if they need since its only created when using our own module resolution.