This updates the SymbolBuilder to no longer use ts.TypeChecker internally to
build symbols for the language service. These lookups are deferred/done later
using the newly expanded template type checker API.
Previously, the Language Service fetched Quick Info and definitions for template variables (such as `@let` declarations) using mapping to their `initializerLocation` (the right-hand side expression). This aggressively bubbled the type, JSDoc, and definition identity of the initializer backwards onto the variable itself.
This approach had two flaws:
1. It broke type narrowing because the LS read the original un-narrowed type from the source expression rather than the type of the narrowed intermediate variable in the Type Check Block.
2. It deviated from native TypeScript semantics, where a local `let` binding (`let address = hero.address`) does not inherit the docstrings or `(property)` kind of its initializer, acting solely as a local inferred variable.
By using `localVarLocation` rather than `initializerLocation` for LetDeclaration Quick Info and Type Definitions, these intermediate variables now properly preserve type narrowing within templates and flawlessly match the standard behavior expected of TypeScript block variables. `VariableSymbol.initializerLocation` is retained solely to map the value spans of structural directive contexts (e.g., `exportAs` strings).
fixes#65491
(cherry picked from commit 75ac120493)
Partially rolls back to using TypeScript 5.9 for the builds on the patch branch, because we bundle our TypeScript version with the language service which can introduce unexpected breakages for users.
Note that we still allow users to install TypeScript 6.
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.
(cherry picked from commit 39f62fa408)
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
Update `ts_plugin.ts` to use the TypeScript instance provided by the
editor during initialization instead of a local import. This prevents
potential issues caused by version mismatches between the plugin's
internal TypeScript dependency and the version used by the host.
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
Updates the template type checker to support arrow functions. The main challenge was getting the current infrastructure not to rewrite references to arrow function parameters.
This commit updates the TypeScript configuration across the project to use `moduleResolution: "bundler"`. This modernizes our module resolution strategy to align with current TypeScript best practices and bundler behaviors.
The following changes are included:
- Updated `tsconfig.json` files to set `moduleResolution` to `"bundler"`.
- Updated the `rules_angular` bazel dependency to a version compatible with these changes.
- Adjusted related test files and golden files to reflect the new module resolution strategy.
PR Close#64125
Type checking of host bindings was added in v20. We're now confident enough in it to enable it by default.
BREAKING CHANGE:
* Previously hidden type issues in host bindings may show up in your builds. Either resolve the type issues or set `"typeCheckHostBindings": false` in the `angularCompilerOptions` section of your tsconfig.
PR Close#63654
In the context of TypeScript (TS), a re-exported symbol is considered a distinct symbol.
This means that a developer can choose to import either the re-exported symbol or
the original symbol. However, in the context of Angular, the re-exported symbol
is treated as the same component because it uses the same selector.
This pull request will utilize the most recent re-export component file to
resolve the module specifier.
PR Close#62585
Deprecated diagnostics can appear on the context guard becaues the
directive itself may be deprecated.
For example, context guards look like `if (i1.NgForOf.ngTemplateContextGuard(_t8, _t9) /*331,378*/) {...}`
and typescript will report the deprecation on the whole element, from
start to end tag, because the span for that node includes it.
fixes https://github.com/angular/vscode-ng-language-service/issues/2203
PR Close#63054
using the `getSymbol` instead of the `type.symbol`, for the primitive type,
the `type.symbol` returns the `undefined` value. The return type of `getSymbol`
includes `undefined`, while `type.symbol` does not.
For example:
```ts
class BarComponent {
/**
* @deprecated
*/
name = ""
}
```
The type of `name` is `string`, the `type.symbol` for the `string`
returns `undefined` here.
e3ef7ff50d/src/services/types.ts (L111)e3ef7ff50d/src/compiler/types.ts (L6445)
PR Close#63002
In the Typescript Language Service, these diagnostics are reported as suggestion diagnostics.
This will report the deprecated `Component`, `Directive`, etc.
Fixes https://github.com/angular/angular/issues/59343
PR Close#62054
Currently when there's a parser error in interpolated text, the compiler reports an error on the entire text node. This can be really noisy in long strings.
These changes switch to reporting the errors on the specific expressions that caused them.
PR Close#62258
Adds support for `getEncodedSemanticClassifications` to the language service.
The service now classifies components in a template as the `class` type.
PR Close#60260
When providing the code action for the directive that is exported by multiple modules
in different files, the directive must save all the TS completion entry data
for every module to compute the module specifier.
When providing a completion item, because the LS only supports displaying one directive
at a time, the first one will be picked.
PR Close#62100
Support to add the missing required inputs into the element and append
after the last attribute of the element.
But it skips the structural directive shorthand attribute. For example,
`<a *ngFor=""></a>`, its shorthand is `<ng-template ngFor>`, the `valueSpan`
of the `ngFor` is empty, and the info is lost, so it can't use to insert
the missing attribute after it.
PR Close#50911
This works for the code actions and completion. When the ls wants to complete
all importable angular metadata in the template, the ls will invoke the function
`ls.getCompletionsAtPosition` and filter the item about the angular. When the
developer selects an item, the ls will get the module specifier from the code action
return by the `ls.getCompletionEntryDetails`.
PR Close#61122
Follow-up to #61240 that adds renaming support for selectorless components/directives both from the template and from the TypeScript source.
PR Close#61307
As part of the Bazel toolchain migration we noticed that implicit types
generated by the TypeScript compiler sometimes end up referencing types
from other packages (i.e. cross-package imports).
These imports currently work just because the Bazel `ts_library` and
`ng_module` rules automatically inserted a `<amd-module
name="@angular/x" />` into `.d.ts` of packages. This helped TS figure
out how to import a given file. Notably this is custom logic that is not
occuring in vanilla TS or Angular compilations—so we will drop this
magic as part of the toolchain cleanup!
To improve code quality and keep the existing behavior working, we are
doing the following:
- adding a lint rule that reduces the risk of such imports breaking. The
failure scenario without the rule is that API goldens show unexpected
diffs, and types might be duplicated in a different package!
- keeping the `<amd-module` headers, but we manually insert them into
the package entry-points. This should ensure we don't regress
anywhere; while we also improved general safety around this above.
Long-term, isolated declarations or a lint rule from eslint-typescript
can make this even more robust.
PR Close#61312
Adds an initial implementation for finding references and renaming to selectorless components/directives.
Finding references should work everywhere, whereas renaming only currently works when initiated from the template.
PR Close#61240
