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
This commit converts the typescript import in api.ts to a type-only import
and updates the plugin factory to utilize standard TypeScript server types.
Internal interfaces and specific service types are replaced with general
types to decouple the factory wrapper from internal implementations.
This commit expands the VScode integration of the signal input migration
to allow migration of full classes and all their inputs. This enables a
faster workflow than just migrating every member individually.
In addition, we now properly support migrating classes that are
unexported and no actual metadata is available in `ngtsc` (but this is
fine for the migration).
PR Close#57975
Add a check to the language service that ignores specified diagnostic codes. This will be useful in g3.
The codes to ignore are exposed as part of the PluginConfig.
Fixes github.com/angular/vscode-ng-language-service/issues/1243
PR Close#57675
VSCode explicitly split code actions into two stages:
- what actions are active?
- what are the edits, if the user presses the button.
The latter stage may take longer to compute complex edits, perform
analysis. This stage is currently implemented via our non-LSP standard
`applyRefactoring` method. We should make it asynchronous, so that it
can easily integrate with migrations that aren't synchronous/or compute
in parallel.
Long-term we may want to revisit this given integration in 1P with the
language service as an actual TS server plugin; but it's not necessary
right now and we shouldn't block the effort on this for now.
PR Close#57214
This is a performance optimization that would exit early when
code actions are requested, but we know Angular cannot provide fixes
based on the error codes.
Previously, we would unnecessarily compute and analyze the application
for semantic diagnostics.
This will be helpful for: https://github.com/angular/vscode-ng-language-service/pull/2050
PR Close#57000
In addition to quick fixes, this commit adds the ability to write
code refactoring actions that can be applied by users.
For example, we may implement a migration as a code refactoring action.
Notably the quick fix support, existing already, is insufficient as it
only allows for edits to be applied based on diagnostics shwon in e.g.
VSCode.
PR Close#56895
Enables the new `@let` syntax by default.
`@let` declarations are defined as:
1. The `@let` keyword.
2. Followed by one or more whitespaces.
3. Followed by a valid JavaScript name and zero or more whitespaces.
4. Followed by the `=` symbol and zero or more whitespaces.
5. Followed by an Angular expression which can be multi-line.
6. Terminated by the `;` symbol.
Example usage:
```
@let user = user$ | async;
@let greeting = user ? 'Hello, ' + user.name : 'Loading';
<h1>{{greeting}}</h1>
```
Fixes#15280.
PR Close#56715
In order to allow both signals and non-signals in two-way bindings, we have to pass the expression through `ɵunwrapWritableSignal`. The problem is that the language service uses a bundled compiler that is fairly new, but it may be compiling an older version of Angular that doesn't expose `ɵunwrapWritableSignal` (see https://github.com/angular/vscode-ng-language-service/issues/2001).
These changes add a `_angularCoreVersion` flag to the compiler which the language service can use to pass the parsed Angular version to the compiler which can then decide whether to emit the function.
PR Close#54423
When the `ts.Project` creates the language service plugin (in this case,
the Angular Language Service), it sets the project's language service to
the new language service returned by the plugin create:
https://sourcegraph.com/github.com/microsoft/TypeScript@b12af0fa2bbd4b015e59adcfb49988cea7f919a1/-/blob/src/server/project.ts?L2035-2044
The project may be reloaded in response to various events, such as a
change to the tsconfig file, which then recreates the plugin. When this
happens, the language service that gets passed to the plugin `create`
function will not be the typescript language service, but rather the
previous instance of the new language service returned by the last call
to `create`.
This commit ensures that subsequent calls to `create` for the
`NgLanguageService` plugin for a project after the first call are able
to retrieve and hold on to the _TypeScript_ language service.
fixes https://github.com/angular/vscode-ng-language-service/issues/1923
PR Close#51912
This commit removes the option to enable the VE language service and removes the VE bundle entirely.
It also updates the name of the ivy bundle to "language-service.js" now that there is only one.
PR Close#43723
As outlined in the previous commit which enabled the `esModuleInterop`
TypeScript compiler option, we need to update all namespace imports
for `typescript` to default imports. This is needed to allow for
TypeScript to be imported at runtime from an ES module.
Similar changes are needed for modules like `semver` where the types incorrectly
suggest named exports that will not exist at runtime when imported from ESM.
This commit refactors all imports to match with the lint rule we have
configured in the previous commit. See the previous commit for more
details on why certain imports have been changed.
A special case are the imports to `@babel/core` and `@babel/types`. For
these a special interop is needed as both default imports, or named
imports break the other module format. e.g default imports would work
well for ESM, but it breaks for CJS. For CJS, the named imports would
only work, but in ESM, only the default export exist. We work around
this for now until the devmode is using ESM as well (which would be
consistent with prodmode and gives us more valuable test results). More
details on the interop can be found in the `babel_core.ts` files (two
interops are needed for both localize/or the compiler-cli).
PR Close#43431
This method is the @angular/language-service side of the implementation
for https://github.com/angular/vscode-ng-language-service/issues/1485
Given a location in a file, if the location is inside a component,
`getTemplateLocationForComponent` will return the `DocumentSpan` of the
inline `template` or the `DocumentSpan` for the file that the
`templateUrl` points to.
PR Close#43208
This commit adds a new configuration option, `forceStrictTemplates` to the
language service plugin to allow users to force enable `strictTemplates`.
This is needed so that the Angular extension can be used inside Google without
changing the underlying compiler options in the `ng_module` build rule.
PR Close#41062
Currently there are two entry points for the `@angular/language-service`
package:
- `@angular/language-service`
This default entry point is for View Engine LS. Through the redirection
of `main` field in `package.json`, it resolves to
`./bundles/language-service.js`.
- `@angular/language-service/bundles/ivy.js`
This secondary entry point is for Ivy LS.
TypeScript recently changed the behavior of tsserver to allow only package
names as plugin names [1] for security reasons. This means the secondary
entry point for Ivy LS can no longer be used.
We implemented a quick hack in the module resolver (in the extension repo)
to fix this, but the long term fix should be in `@angular/language-service`.
Here, the `main` field in `package.json` is changed to `index.js`, and in the
index file we conditionally load View Engine or Ivy based on the input config.
This eliminates the need for multiple entry points.
As part of this PR, I also removed all source code for View Engine and Ivy
included in the NPM package. Consumers of this package should run the bundled
output and nothing else. This would help us prevent an accidental import that
results in execution of unbundled code.
[1]: https://github.com/microsoft/TypeScript/pull/42713
PR Close#40967
Two motivations behind this change:
1. We would like to expose the types of the Language Service to external
users (like the VSCode extension) via the npm package, on the top
level of the package
2. We would like the View Engine and Ivy LS to share a common interface
(notably after the inclusion of `getTcb`, the Ivy LS upholds a
strict superset of `ts.LanguageService`; previously both VE and Ivy
LS were aligned on `ts.LanguageService`.)
To this end, this commit refactors the exports on the toplevel of the
`language-service/` package to just be types common to both the VE and
Ivy language services. The VE and Ivy build targets then import and use
these types accordingly, and the expectation is that an external user
will just import the relevant typings from the toplevel package without
diving into either the VE or Ivy sources.
Follow up on #40607
PR Close#40621
