Andrew Scott
13fad9febe
When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes https://github.com/angular/vscode-ng-language-service/issues/1623 fixes https://github.com/angular/vscode-ng-language-service/issues/876 PR Close #45601
Override Rename Ts Plugin
When the user wants to rename a symbol in the ts file VSCode will ask the rename providers for the answer in turn. If the first extension returns the result, the VSCode will break the loop and apply the result. If the first extension cannot rename the symbol, VSCode will ask the second extension in the list (built-in TS/JS extension, Angular LS extension, etc.). In other words, VSCode takes the result from only one rename provider and the order depends on registration timing, scoring.
Because the built-in ts extension and Angular extension have the same high score, if the built-in ts extension is the first(depends on the time the extension was registered), the result will be provided by the built-in extension. We want Angular to provide it, so this plugin will delegate rename requests and reject the request for the built-in ts server.
The Angular LS only provides the rename info when working within an Angular project. If we cannot locate Angular sources in the project files, the built-in extension should provide the rename info.
This plugin will apply to the built-in TS/JS extension and delegate rename requests to the Angular LS. It provides the rename info only when it is an Angular project. Otherwise, it will return info by the default built-in ts server rename provider.
See here for more info.