Resolve modules, type reference directives in context of referenced file

[sheetalkamat]

This PR adds the ability to resolve module and type reference directives in the project direct file with its own options (eg project structure of A -> B -> C, while resolving modules/type reference directives in B we will use B's config file options to resolve it rather than using A's config file options)
Fixes #27200

[ajafff]

Wow, there's a heck of a lot changes in this PR.
I'm not sure I understand why all of them are necessary. So maybe the approach presented below doesn't fulfil all requirements.

My approach would more closely align with the old implementation:

• parse projectReferences recursively (like this PR does)
• resolve imports and type references as if there were no project references at all
  • of course using the compilerOptions of the containing project of the current file
  • module resolver doesn't need to know about project references at all
• map resolved path to declaration file of project reference if necessary (taking only direct references of the current containing project into account) like the old implementation
• moduleResolutionCache depends on the current containing project's compilerOptions
  • maybe you could even reuse the parent's cache if the compilerOptions of a project reference doesn't differ in options that affect module resolution

That way you could get rid of all changes in moduleNameResolver.ts and probably all of the public API changes.

[sheetalkamat]

module resolver passes current project reference so it can use the compiler options of the containing project. (instead of options it passes Project Reference since it is more future proof.) The changes in module resolver are needed so it can use compiler options of containing project instead of project it is building.

[ajafff]

I agree that it makes sense to pass compilerOptions to CompilerHost.resolveModuleNames and CompilerHost.resolveTypeReferenceDirectives. But I don't think the module resolver should know about the concept of project references.

[sheetalkamat]

I don't think just passing compilerOptions is good idea since the current way (passing containing projectReference which sourceFile of config file apart from its commandline) lets host do custom action eg. your build expecially in watch mode or editor could reuse the resolution from that cache - this is not yet part of this change but its intended for future use.

[weswigham]

Haven't looked at it in detail yet, but the approach made me want to see a test of a node module resolution project referencing a non-node one and vice versa (and ensuring the, eg, if a classic project referenced a node project, node module identifiers resolve in the declarations representing the dependent project).

[sheetalkamat]

I can add classic resolution in referenced project test case but note that in the current one I verify path mapping changes in referenced project are handled correctly.

[weswigham]

I specifically am calling out a change in module resolution scheme because they use differing underlying resolvers.

[ajafff]

when resolving module names in the root project, there will be no ResolvedProjectReference. Therefore a custom CompilerHost has no access to the CompilerOptions of that project.

[sheetalkamat]

That is not changed since it was original API as well. In general host already knows root compiler options. Eg. https://github.com/TypeStrong/ts-loader/blob/master/src/servicesHost.ts#L498

[ajafff]

In general host already knows root compiler options.

Correct, although that only works when building exactly one project with that host. The current implementation of tsbuild.ts (I know it's still considered internal) uses the same SolutionBuilderHost to build all projects. That host cannot know about the compilerOptions of all projects. And since tsbuild can even handle multiple tsconfig.json files at once, there's no way the host could ever know the correct compilerOptions.

[sheetalkamat]

I don't think we want to change that. (the default compilerHost is for specific compilerOptions) Infact we want to change tsbuilder to create compiler host for each program separaterly but that's a todo for little later.

[sheetalkamat]

@weswigham @rbuckton Please review.