-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revised module resolution #4154
Conversation
…ts/references, remove module resolution from the checker
…dule kind differs in old and new programs, move setting of resolvedModules cache to the program, added tests
…nsion to the end of the list
Excited 🌹 ! |
adding @dbaeumer, @derekcicerone, @mhegazy |
@@ -129,6 +129,10 @@ class ProjectRunner extends RunnerBase { | |||
getSourceFileText: (fileName: string) => string, | |||
writeFile: (fileName: string, data: string, writeByteOrderMark: boolean) => void): CompileProjectFilesResult { | |||
|
|||
let moduleResolutionHost: ts.ModuleResolutionHost = { | |||
fileExists: fileName => getSourceFile(fileName, ts.ScriptTarget.ES5) !== undefined, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would use Harness.IO.fileExists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Neat, looks like this could be used for modules which need to be resolved across project boundaries perhaps. |
return normalizePath(referencedFileName); | ||
} | ||
|
||
function resolveModuleName(moduleName: string, containingFile: string, compilerOptions: CompilerOptions, host: ModuleResolutionHost): ResolvedModule { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
function resolveModuleName(moduleName: string, containingFile: string, compilerOptions: CompilerOptions, host: ModuleResolutionHost): ResolvedModule {
switch(compilerOptions.module) {
case ModuleKind.CommonJS:
resolveCommonJSModuleName(....);
//...
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
👍 |
Just wanted to comment that I recently added support for this to ts-loader for resolving modules the same way that webpack does (setting up aliases and such) and it's fantastic. This is a great addition to TypeScript! Good work. |
Great to hear that! |
This PR consolidates all module resolution logic in one place so there is only one entry point for everything that needs to resolve module names. Currently it is function
getDefaultModuleNameResolver
function that acceptsCompilerOptions
and returns back an instance ofModuleResolved
which is the alias forexport type ModuleNameResolver = (moduleName: string, containingFile: string, options: CompilerOptions, host: ModuleResolutionHost) => ResolvedModule;
. Default module resolver is used in several places:preProcessFile
that is called from VS to determine dependencies of the filecreateProgram
- at this point default module resolver will be requested if host wants to process with default module name resolution rules. NOTE: host can override built-in rules by implementingresolveModuleNames?(moduleNames: string[], containingFile: string): string[];
function that accepts a list of imported names in the file and returns a list of resolved file names in the same order.resolveModuleNames
implementation inLSHost
for 'tsserver'.Now
CompilerHost / LanguageServiceHost
can implementresolveModuleNames
and be completely in control of how module names are resolved. Alternatively they might want to use built-in rules - in this case they should implementgetModuleResolutionHost
, return value of this function will be used by default module resolver to ask file system related questions.