{{ message }}
fix(vscode-extension): handle template literals when detecting supported decorator fields - #70571
Open
aparzi wants to merge 1 commit into
Open
fix(vscode-extension): handle template literals when detecting supported decorator fields#70571aparzi wants to merge 1 commit into
aparzi wants to merge 1 commit into
Conversation
…ted decorator fields
The client decides whether a position in a TypeScript file belongs to a supported `@Component` field (`template`, `styles`, ...) with a lightweight `ts.Scanner` loop before forwarding requests to the language server and the HTML/CSS providers. `ts.Scanner#scan` doesn't handle template substitutions on its own: the `}` closing a `${...}` substitution is reported as a plain `CloseBraceToken` and the rest of the template literal is scanned as the start of a new one, swallowing everything up to the next backtick. As a result, once a template literal with substitutions appears in a file, every position after it is considered to be inside a template string, and TypeScript completions get polluted with HTML completions.
The scanner is now driven the same way the TypeScript parser does it, re-scanning the brace that closes a substitution as a `TemplateMiddle`/`TemplateTail` token.
In addition, the property assignment context previously only ended at a terminator found at the top level of the file, so it leaked from `template:` to every string literal that followed it inside the same decorator and class body. The context now ends at the first terminator found at the nesting depth where it was entered. Two kinds of strings were only recognized thanks to that leak, and only when declared after `template`: inline `styles` and the arguments of `@HostBinding`/`@HostListener` decorators, both of which the language service supports. They are now recognized explicitly, regardless of where they appear.
Fixes angular#65494
angular-robot
Bot
added
the
area: vscode-extension
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
1 participant
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.
The client decides whether a position in a TypeScript file belongs to a supported
@Componentfield (template,styles, ...) with a lightweightts.Scannerloop before forwarding requests to the language server and the HTML/CSS providers.ts.Scanner#scandoesn't handle template substitutions on its own: the}closing a${...}substitution is reported as a plainCloseBraceTokenand the rest of the template literal is scanned as the start of a new one, swallowing everything up to the next backtick. As a result, once a template literal with substitutions appears in a file, every position after it is considered to be inside a template string, and TypeScript completions get polluted with HTML completions.The scanner is now driven the same way the TypeScript parser does it, re-scanning the brace that closes a substitution as a
TemplateMiddle/TemplateTailtoken.In addition, the property assignment context previously only ended at a terminator found at the top level of the file, so it leaked from
template:to every string literal that followed it inside the same decorator and class body. The context now ends at the first terminator found at the nesting depth where it was entered. Two kinds of strings were only recognized thanks to that leak, and only when declared aftertemplate: inlinestylesand the arguments of@HostBinding/@HostListenerdecorators, both of which the language service supports. They are now recognized explicitly, regardless of where they appear.Fixes #65494
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Issue Number: #65494
What is the new behavior?
Does this PR introduce a breaking change?