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
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
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 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.
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.
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 commit updates the minimum supported Node.js versions. Node.js v20 support is dropped, and the minimum version for Node.js v22 is bumped to v22.22.0, and for v24 it is bumped to v24.13.1.
BREAKING CHANGE: Node.js v20 is no longer supported. The minimum supported Node.js versions are now v22.22.0 and v24.13.1.
avoid per-file semantic diagnostics work when warming up a newly loaded project.
add ensureProjectAnalyzed() to the language-service API and use it from the server startup path.
implement warmup through public compiler API access with existing perf tracing, and add legacy test coverage for the new warmup flow.
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 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
This addresses a potential memory leak in plugin-factory.ts.
The require call inside the create function reloads the entire language
service module for every new project, which is inefficient and could be a cause of the memory leak during branch
switching. This ensures the module is loaded only once and the same
instance is shared across all projects.
This commit updates the scripts to use the version from `package.json` for snapshot builds, ensuring that the git tags are aligned with the package version. This change simplifies referencing snapshot builds in the `package.json` file.
PR Close#64350
This commit introduces a mechanism to use snapshot builds for @angular/language-service dependencies when building the VSCode extension.
A new --//:enable_snapshot_repo_deps flag allows swapping the stable versioned dependency with a snapshot build from the angular/language-server-builds GitHub repository. This enables testing and development against the latest unreleased version of the language service.
PR Close#64334
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
This change updates the build configuration to include the
@angular/language-server package in the standard framework release
output.
By integrating it into the release train, we ensure that it is versioned and published consistently with the rest of the Angular framework.
PR Close#64306
This commit updates the VSCode Angular Language Service extension to use the `@angular/language-service` package built from source within the workspace, rather than a version downloaded from npm.
This change simplifies development and testing by ensuring the extension always uses the latest code from the local repository. The Bazel build configuration, VSCode launch settings, and e2e tests have been updated to reflect this change.
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
The repository URL in `package.json` is updated to point to the `angular/angular` monorepo. This ensures that the package metadata correctly reflects its location within the main repository.
PR Close#64220
The supported Node.js versions for the language service server are updated to align with the versions supported by Angular. This ensures a consistent and stable environment for developers.
PR Close#64220
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
This commit refactors the VSCode extension's build and launch configurations to align with `vsce` and `pnpm` workspaces.
The following changes are included:
- Updated `.vscode/launch.json` to use new `vsce:` prefixed tasks and simplified launch configurations.
- Updated `.vscode/tasks.json` to use `pnpm` workspace commands for watching and packaging the extension.
- Adjusted `BUILD.bazel` and `package.json` files to reflect the new build output paths.
These changes streamline the development workflow for the VSCode extension, making it easier to build, debug, and package.
PR Close#64220
Angular Robot