Paul Gschwendtner
2e60eb08f4
Migrations may resolve files in e.g. `blaze-out` and try to compute a path for the file that is "recognizable" across workers. E.g. in one worker, it may be the actual `.ts` file inside the source tree, while in the other, the file may be inside `blaze-out`. Tsurge currently expects project relative paths to be passed around. Those project relative paths are currently only based on the single root directory. Hence paths inside `blaze-out` would actually not be recognizable. The fix idea here is that we introduce a structure for Project files. This structure will contain two fields: - an ID of a file. This is similar to a module ID in the project. Those are resolved with respect to all root directories. This matches the conceptual virtual roots of `tsconfig#rootDirs`. The IDs can be used for matching files across workers, assuming those are executing using the same root directories, and handle the same overall project (e.g. google3). - a path relative to the primary project root. Multiple roots may be configured, but the primary project root, is the directory that contains all others. See: `tsconfig.rootDir`. This path is NOT necessarily useful for matching files between stages etc, but it's useful for writing replacements for a given file to disk. Note that those two things cannot be combind into one conceptual "project relative path" because a path relative to the most appropriate root directory cannot be used for safe replacements. E.g. consider a replacement matches a file from a root directory like `/sub/`. The path inside `/sub/` would then omit the `/sub/` and later on when writing replacements, we wouldn't know which root directory it actually was part of. Hence the concept of a "project root relative path" and the "ID". ds PR Close #57677
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.