Skip to content
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

Merged
merged 28 commits into from
Aug 17, 2015
Merged

Revised module resolution #4154

merged 28 commits into from
Aug 17, 2015

Conversation

vladima
Copy link
Contributor

@vladima vladima commented Aug 4, 2015

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 accepts CompilerOptions and returns back an instance of ModuleResolved which is the alias for export 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 file
  • createProgram - 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 implementing resolveModuleNames?(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 in LSHost for 'tsserver'.

Now CompilerHost / LanguageServiceHost can implement resolveModuleNames 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 implement getModuleResolutionHost, return value of this function will be used by default module resolver to ask file system related questions.

@vladima
Copy link
Contributor Author

vladima commented Aug 4, 2015

In theory existing implementation of LanguageServiceHost interface should just work because of this. Pinging @basarat so he can be aware of this change.

@basarat
Copy link
Contributor

basarat commented Aug 4, 2015

Excited 🌹 !

@vladima
Copy link
Contributor Author

vladima commented Aug 4, 2015

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,
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@derekcicerone-zz
Copy link

Neat, looks like this could be used for modules which need to be resolved across project boundaries perhaps.

@mhegazy mhegazy mentioned this pull request Aug 5, 2015
return normalizePath(referencedFileName);
}

function resolveModuleName(moduleName: string, containingFile: string, compilerOptions: CompilerOptions, host: ModuleResolutionHost): ResolvedModule {
Copy link
Contributor

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(....);
             //...
    }
}   

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@mhegazy
Copy link
Contributor

mhegazy commented Aug 17, 2015

👍

@jbrantly
Copy link

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.

@vladima
Copy link
Contributor Author

vladima commented Aug 29, 2015

Great to hear that!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants