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
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
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
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.
Add DocumentSymbol provider for Angular templates, surfacing structural
elements like components, directives, control flow blocks, and template variables
in the VS Code Outline and breadcrumbs.
resolves#65488
Add Angular template inlay hints end-to-end across language-service and VS Code extension server/client wiring, including inlay-specific configuration mapping, request guards, and refresh behavior.
This refactoring improves the lifecycle management and configuration handling within the VS Code extension's language client.
Key changes include:
- Introduced sessionDisposables to manage resources tied to the lifespan of an LSP client session, ensuring they are properly cleaned up when the client stops without affecting global extension resources.
- Added a configuration change listener to clear the fileToIsInAngularProjectMap cache, ensuring project state is re-evaluated when settings change.
- Enhanced registerNotificationHandlers to clear the project state cache when project loading begins or completes, providing more accurate "is in Angular project" checks.
- Modified isInAngularProject to only cache positive results, allowing for recovery if a file was initially incorrectly identified as being outside an Angular project.
This feature enables synchronized editing of opening and closing HTML tag pairs
in Angular inline templates. When the cursor is on an element tag name, editing
it will automatically update the corresponding tag.
Implementation:
- Add getLinkedEditingRangeAtPosition method to NgLanguageService interface
- Implement linked editing range detection for opening and closing tags
- Handle edge cases: self-closing elements, void elements, cursor detection
- Export through ts_plugin wrapper to override TypeScript JSX-only implementation
- For external HTML templates, VS Code built-in HTML support handles linked editing
This updates the language service to use the detected version of angular
core in the given project on load rather than the minimum detected
version in the workspace
This implements `onDidChangedWatchedFiles` in the language server, which
allows the client to communicate changes to files rather than having the
server create system file/directory watchers.
This option is enabled in the extension via the
`angular.server.useClientSideFileWatcher` setting.
When enabled, the extension registers a FileSystemWatcher for .ts, .html, and package.json files and forwards events to the server. The server completely disables its internal native file watchers (via a new 'ServerHost' implementation that stubs watchFile/watchDirectory).
This is significantly more performant and reliable than native watching for several reasons:
- Deduplication: VS Code already watches the workspace. Piggybacking on these events prevents the server from duplicating thousands of file watchers.
- OS Limits: Since the server opens zero watcher handles, it is impossible to hit OS limits (ENOSPC), no matter how large the repo is.
- Optimization: VS Code's watcher uses highly optimized native implementations (like Parcel Watcher in Rust/C++) which handle recursive directory watching far better than Node.js's 'fs.watch'.
- Debouncing: The client aggregates extremely frequent file events (e.g., during 'git checkout'), reducing the flood of processing requests to the server.
This option was tested in one very large internal project and observed
~10-50x improvement of initialization times.
fixes#66543
0.0.0 is the version in the local repo when building from sources. Update the
extension to see this as some arbitrarily large version so it uses the most recent features
This shows a more prominent warning when multiple versions of Angular
are detected in the workspace and we are forced to choose one to use for
the language server. This also logs those versions with their locations
and directs the user to view the output panel.
fixes#65466
This commit migrates the vscode-ng-language-service to use the in-repo `ts_project` macro, which has strict dependency checking enabled. This improves build-time dependency validation and helps ensure that all dependencies are explicitly declared.
As part of this change, redundant `tsconfig.json` files have been removed in favor of a centralized configuration, and `jasmine_test` rules have been updated to the standard macro. A minor code adjustment in `server/src/session.ts` was also made to improve error handling.
PR Close#64306
The legacy `workspace` integration test asset folder has been removed as it was unused and no longer representative of modern Angular CLI workspaces.
In line with this cleanup, the Bazel dependency definitions for the integration tests have been reorganized. Runtime data dependencies have been moved from the `js_test` rules to the `data` attribute of their corresponding `ts_project` rules. This is a cleaner and more appropriate approach as it co-locates a test's runtime data dependencies with its source code definition, making the relationship between the code and its required assets more explicit and improving the overall maintainability of the build configuration.
PR Close#64271
This commit revamps the debugging setup and enabling developers to set breakpoints directly in the source TypeScript files.
Key changes include:
- Updated `launch.json` with source map path overrides to correctly map compiled output back to the original source code.
- Switched from `external` to `linked` sourcemaps in the Bazel build configuration for better debugging support.
- Consolidated the recommended VSCode settings into the main `launch.json` and `tasks.json`, removing the separate `recommended-*.json` files.
- Updated the debugging documentation to reflect the new, simplified workflow.
These changes significantly improve the developer experience for contributors working on the language service, making it much easier to debug and troubleshoot issues.
This applies to both the framework packages and vscode-ng-langugage-service.
PR Close#64220
The VS Code extension build is failing due to some dependency issues. This commit updates the dependencies and build configuration to fix the build.
- Update `pnpm-lock.yaml` to reflect the dependency changes.
- Update `BUILD.bazel` files to adjust the external dependencies for `esbuild` and to correctly package the VSIX file.
PR Close#64154
This commit updates several dependencies to their latest versions and adjusts the build configurations accordingly.
Key changes include:
- Upgraded various development and runtime dependencies.
- Removed outdated jasmine test runner configuration.
- Updated Bazel build files to align with new dependency structures.
Some dependencies like `vscode-language*` have been added to Renovate's ignore list as they require a more significant refactoring effort that is planned for a future update.
PR Close#64073
aparziale