fix(language-server): recover project for external templates in solution-style workspaces#69769
Open
ShayanAbbas1 wants to merge 1 commit into
Open
Conversation
…ion-style workspaces In a composite/solution-style workspace (e.g. an Nx monorepo, where an app's tsconfig.json only contains project references), TypeScript can never resolve a config file for an HTML file, since HTML files are not listed in any referenced project. angular/vscode-ng-language-service#2165 worked around this in onDidOpenTextDocument by briefly opening the sibling TS file so the right project loads when a template is opened first. However, getDefaultProjectForScriptInfo - the recovery path used by getLSAndScriptInfo and onDidChangeTextDocument when a script info has no configured project - did not receive the same workaround. When an open template loses its project association (e.g. its component file is closed and the project graph updates), every subsequent request on the template fails with "No config file" and returns null indefinitely, until the user manually reopens the component file. Apply the same sibling-TS best effort in getDefaultProjectForScriptInfo, and additionally attach the template's script info to the configured project of its component when the config lookup still comes back empty (openClientFile does not repeat the config lookup for already-open files). Fixes angular#69768
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
pkozlowski-opensource
added
the
area: language-service
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Checklist
PR Type
What is the current behavior?
In solution-style workspaces (the default Nx layout, where an app's
tsconfig.jsoncontains only project references), an external template that loses its configured-project association after being opened — e.g. because its component.tsfile was closed and the project graph updated — permanently loses all language service features. Every subsequent request on the template hitsgetDefaultProjectForScriptInfo, whose bareopenClientFilelookup can never resolve a config file for an HTML file, so it logsNo config file for ...and returnsnullindefinitely until the user manually reopens the component file.angular/vscode-ng-language-service#2165 fixed this same failure mode for the document-open path only; the request-time recovery path was left unpatched.
Reproduced in VS Code itself (Angular extension v22.0.1, server 22.x) with a template-opened-first session, in Zed, and with a raw LSP stdio client — details and Angular Language Service logs in #69768.
Issue Number: Fixes #69768
What is the new behavior?
getDefaultProjectForScriptInfoapplies the same best-effort asonDidOpenTextDocumentwhen the config lookup comes back empty for an external template: briefly open/close the sibling.tsfile (guarded byprojectService.openFiles, same as #2165) and retry. If the lookup still fails —openClientFiledoes not repeat the config search for an already-open file — the template's script info is attached directly to the configured project of its component.Validated against a large Nx monorepo (Angular 19, ~30 projects) by driving
@angular/language-serverover raw LSP: with stock 21.1.5, definition requests on an orphaned template fail withNo config fileindefinitely (40+ consecutive failures reproduced); with this change the template re-attaches on the next request and features recover every time. This patch has also been in daily editor use (Zed) on that workspace.Note on tests:
server/src/session.tscurrently has no unit spec, and the integration fixtures underintegration/projectare not solution-style. Happy to add a solution-style fixture + integration test if the reviewers can point me at the preferred shape.Does this PR introduce a breaking change?