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#65494
Add support for the new `@boundary` and `@error` control flow blocks in the Angular Language Service.
This includes:
- Updating outlining spans to handle boundary blocks correctly.
- Adding classification visitor methods for semantic tokens.
- Adding template target visitor methods for navigation and hover support.
- Updating the TextMate grammar to recognize `@boundary` and the `when` clause.
PR Close#70463
The TextMate grammars for inline templates and inline styles ended the
string at the first occurrence of the delimiter, so an escaped delimiter
(e.g. \`) terminated the highlighting prematurely and the rest of the
template was no longer highlighted as HTML.
Escape sequences are now consumed before delegating to the HTML/CSS
grammars, so escaped delimiters no longer end the string. Also removes
the stray pipes from the string delimiter character class, which
unintentionally matched a literal '|'.
Fixes#65493
`stableTypeOrdering` was recently enabled in the internal builds. While there aren't any breakages in Angular, these changes enable it so we can catch potential issues earlier.
The quick fix and completion auto-import always generated the module specifier with double quotes, ignoring the user's quote preference and the style used in the file.
The generated import now respects the `quotePreference` from the TypeScript user preferences. When the preference is `auto` (or absent), the style is inferred from the first existing import in the file, mirroring TypeScript's own behavior. Files with no imports
keep the previous double-quote default.
Fixes#67108
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).
Also skip the sibling lookup when the .ts file does not exist, so
non-component HTML files (e.g. src/index.html) do not trigger an
open/close and config search that cannot succeed.
Fixes#69768
VS Code parses notification text for links and permits `command:` URIs. Interpolating the workspace-controlled TSDK path can therefore let a malicious path add a command link to the approval prompt.
Remove the path from the notification instead of attempting to sanitize or escape it. This keeps the prompt static and matches VS Code's TypeScript extension workspace-version approval flow.
Fixes#70176
Previously, the release script hardcoded the upstream repository URL as an unauthenticated HTTPS URL (https://github.com/angular/angular.git). Although the script verified that a GITHUB_TOKEN environment variable was present, it only used that token for REST API calls (such as creating the GitHub release) and did not provide it to Git commands. As a result, users who authenticate to GitHub via SSH (and do not have an HTTPS Git credential helper configured) were prompted interactively for GitHub login credentials when pushing the release tag.
This change dynamically resolves the upstream remote name from the user's configured remotes by checking for any remote pointing to angular/angular. When pushing over SSH, Git uses the user's existing SSH credentials. When pushing over HTTPS (or falling back), the script injects GITHUB_TOKEN into the push URL to prevent interactive authentication prompts.
The completions handler kept a local copy of getTokenAtPosition plus three stale TODO comments noting the duplication, but the function is already exported from server/src/utils.ts (hover.ts and others import it from there). Drop the local copy, import the canonical one, and remove the now-meaningless comments.
Resolve the approved relative workspace tsdk path to an absolute path by checking workspace folders. This ensures the path is correctly resolved on the server side.
Fixes#69276
Previously, when releasing the VS Code extension, the draft release
was created with make_latest: 'false', but the PATCH request that
published the draft release omitted this option. As a result, GitHub
automatically designated the published release as the 'latest' release.
This change explicitly passes make_latest: 'false' during the publish
request to prevent it from automatically becoming the latest release.
session.ts defined isAngularCore, isExternalAngularCore, and
isInternalAngularCore as byte-identical copies of the already-exported
versions in utils.ts. Only isAngularCore was used locally; the other
two were dead. handlers/template_info.ts already imports the utils
version. Remove the duplicates and import isAngularCore from utils.
Update the release tool to create the GitHub release in a draft state initially and publish it only after the extension asset (.vsix) has been successfully uploaded.
GitHub shifted towards immutable releases. If a release is published instantly upon creation,the assets will not be able to be uploaded.
Update the minimum supported Node.js versions for v22 and v24. Specifically, the minimum supported version for Node.js v22 is bumped to v22.22.3, and for v24 it is bumped to v24.15.0. This ensures compatibility with newer runtime versions and coordinates ranges across monorepo packages.
Restrict untrusted workspace support to limited mode. Skip launching the language client and registering commands in restricted mode, and only start them once workspace trust has been explicitly granted.
Since bundled path is at the start of probe locations, it's always going to be found first.
Workspace versions will never be used. getProbeLocations is effectively dead and confusing code.
Harden the typescript.tsdk and js/ts.tsdk.path settings loading
in the VS Code extension client.
This change hardens tsdk loading by:
1. Ignoring workspace-level tsdk paths in untrusted workspaces.
2. Prompting the user for explicit confirmation before loading a
workspace-level tsdk path in trusted workspaces, and saving the
approval state in a secure, local workspaceState.
Updates the supported Node.js engine versions to include Node.js 26.
This allows running the CLI on Node.js 26.0.0 and above while continuing to support active LTS versions.
This change allows to toggle attributes that are on their own line and have a 1+ leading space.
This change doesn't suffer from the issue that was reverted in #68067.
Also this change fixes another regression that messed up highlighting if an attribute value included a '//', like in an href.