Expose compiler API needed for vue #14888
Conversation
1. resolveModuleName 2. create/updateLanguageServiceSourceFile Note that these are the hooks required to implement a typescript language service plugin as in sandersn/vue-ts-plugin. A plugin like octref/vetur that creates its own language service must also create its own host, so it only needs part (2): the create/updateLanguageServiceSourceFile hook.
|
@RyanCavanaugh @mhegazy thoughts? |
|
CI's failing |
| return rmn(moduleName, containingFile, compilerOptions, host, cache); | ||
| } | ||
| }; | ||
| function importInterested(filename: string) { |
| @@ -899,6 +899,13 @@ namespace ts { | |||
| sourceFile.scriptSnapshot = scriptSnapshot; | |||
| } | |||
|
|
|||
| export function overrideCreateupdateLanguageServiceSourceFile( | |||
There was a problem hiding this comment.
this should be a LanguageServiceHost optional functions. we do not want to override this for all instances of the language service.
There was a problem hiding this comment.
I would also recommend splitting this into createSoruceFile and upadateSourceFile.
There was a problem hiding this comment.
These are global functions, so I'm not sure how to avoid overriding them for all instances of the language service. (That was probably the cause of the CI failures; bad overrides are also global.)
There was a problem hiding this comment.
We have two options:
- in
LanguageServiceHost:
export interface LanguageServiceHost {
...
createSourceFile?(fileName: string, scriptSnapshot: IScriptSnapshot, scriptTarget: ScriptTarget, version: string, setNodeParents: boolean, scriptKind?: ScriptKind): SourceFile;
updateSourceFile?(sourceFile: SourceFile, scriptSnapshot: IScriptSnapshot, version: string, textChangeRange: TextChangeRange, aggressiveChecks?: boolean): SourceFile;
....
}Then in the language service, in places where we call ts.createLanguageServiceSourceFile or ts.updateLanguageServiceSourceFile, we can just check the host if it supports these APIs.
- users can wrap the
DocumentRegistryfor the language service, and do the needed work inacquireDocumentandupdateDocument.
src/server/project.ts
Outdated
| @@ -102,6 +102,13 @@ namespace ts.server { | |||
| export interface PluginModule { | |||
| create(createInfo: PluginCreateInfo): LanguageService; | |||
| getExternalFiles?(proj: Project): string[]; | |||
| resolveModules?(createInfo: PluginCreateInfo): PluginResolveModules; | |||
There was a problem hiding this comment.
the plugin already has access to the lshost, it can just override resolveModule directly. not sure i see the need for this new API.
There was a problem hiding this comment.
Technically it does, but I'm not sure whether the API guarantees it. Regardless, it gets rid of a lot of code. @RyanCavanaugh can you take a look at the new commits that override resolveModuleNames on the language service host directly?
Instead, override resolveModuleNames in the provided language service host. This is not technically part of the API, but works fine in the current implementation.
|
After much discussion with @mhegazy, we couldn't figure out a non-global way to override create/updateLanguageServiceSourceFile. I'll close this PR for now and vetur (for example) will continue to override create/update globally. |
resolveModuleNamecreate/updateLanguageServiceSourceFileNote that these are the hooks required to implement a typescript language service plugin as in sandersn/vue-ts-plugin. A plugin like octref/vetur that creates its own language service must also create its own host, so it only needs part (2): the create/updateLanguageServiceSourceFile hook. The host it creates has to provide an implementation of
resolveModuleNamesanyway, so it doesn't need (1).If/when we decide to add these hooks, vetur will need to update the code added in vuejs/vetur#94 to avoid overwriting these functions itself.