Instead of creating instances of refactoring whenever the language
service loads, we should lazily create these upon first "application".
This will speed up loading of the language service, while it also gives
us the ability to implement caching in code refactorings to speed up
subsequent applications; leveraging e.g. the `script versions` from the
TS server project.
PR Close#57645
Instead of some special hook that relies on mutation to filter inputs in
the signal input migration, we are now introducing a new configuration
interface where the language-service can pass a filter method.
This makes the code more readable. We also need the filter method to
support filtering based on directories. E.g. when the migration runs
against sub-folders, all inputs outside of the folder should be
considered incompatible; to not migrate incorrectly.
PR Close#57606
This allows for the replacements to be conveniently passed between
migration stages. This is especially relevant in 1P where stages may
have different root directories.
Tsunami attempts to relativize paths in general, similar to how we do
here, but this doesn't work with e.g. Funnel-based migrations where
replacements are serialized in between stages; and where the migration
stage at the end doesn't know about the previous root directory anymore.
PR Close#57584
(experimental at this point)
Language service refactoring action that can convert `@Input()`
declarations to signal inputs.
The user can click on an `@Input` property declaration in e.g. the VSCode
extension and ask for the input to be migrated. All references, imports and
the declaration are updated automatically.
PR Close#57214
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 allows us to split up the BUILD rules a bit further, so that
refactorings can be their own BUILD target. This is beneficial as
e.g. refactorings may rely on migration code from Angular core etc.
and this allows for more fine-grained visibility and a better conceptual
split.
PR Close#57214
Angular's template files are not valid TypeScript. Attempting to get suggestion
diagnostics from the underlying TypeScript language service will result in
a large amount of false positives. Only actual TypeScript files should
be analyzed by the underlying TypeScript language service for suggestions.
PR Close#56241
Adds a new extended diagnostic that will flag `@let` declarations that aren't used within the template. The diagnostic can be turned off through the `extendedDiagnostics` compiler option.
PR Close#57033
Adds a new extended diagnostic that will flag `@let` declarations that aren't used within the template. The diagnostic can be turned off through the `extendedDiagnostics` compiler option.
PR Close#57033
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
When importing a component exported by default, the `default` can't be
used as the component name.
For example:
This is the export declarations:
```ts
export default class TestComponent {}
```
Previously, the output generated by LS looked like this:
```ts
import { default } from "./test.component";
```
Now the output looks like this:
```ts
import TestComponent from "./test.component";
```
Fixes#48689
PR Close#56432
This PR allows the language service to suggest imports for all directives returned from the
compiler, and generate the TypeScript module import and the decorator import when the component
is selected by the user.
PR Close#55595
Introduces a new `LetDeclaration` into the Render3 AST, simiarly to the HTML AST, and adds an initial integration into the various visitors.
PR Close#55848
An implementation of a TypeScript server plugin module factory has
been added to the main plugin code which minimizes the amount of
infrastructure code necessary to directly setup the Angular plugin.
This is not yet used externally but can be integrated in the future.
PR Close#55264
The `getDefinitionAtPosition` function may be called by consumers instead
of `getDefinitionAndBoundSpan` with the later of which already implemented.
The `getDefinitionAtPosition` result is a subset of what `getDefinitionAndBoundSpan`
returns and currently delegates to that function.
PR Close#55269
Within the language service, the Angular compiler instance can provide
access to the current TypeScript program via `getCurrentProgram`. By
using the compiler, the need to pass around the program driver is no longer
required and can also be removed as an instance field of the Angular language
service class. This change also provides a higher assurance that the correct
program is being used throughout each language service request.
PR Close#55097
Angular's template files are not valid TypeScript. Attempting to get syntactic
diagnostics from the underlying TypeScript language service will result in
a large amount of false positive errors. Only actual TypeScript files should
be analyzed by the underlying TypeScript language service for syntactic errors.
PR Close#55091
The custom flatMap implementation can now be removed as Array contains a
native implementation that is available for all supported Node.js versions.
PR Close#55011
When the `angularOnly` option is disabled, the underlying TypeScript language service
was previously used for all files including `.html` template files. This can result in
incorrect responses including a large amount of invalid diagnostics for a template file.
Checks have now been added to only use the Angular Language service for template files
which can properly handle template files. Additionally, the check for a TypeScript file
name has now been expanded to encompass all current file extension forms.
PR Close#55003
Adds logic to ingest the content of an `ng-content` element in the template type checker. We treat `ng-content` as a `ScopedNode`, because its content is inserted conditionally.
PR Close#54854
When creating the Angular Language Service instance, attempts to read
configuration files are now only attempted if the project is considered
a `Configured` project. Such a project has been analyzed by TypeScript
and one or more configuration files (tsconfig/jsconfig) files have been
found for the project.
PR Close#55035
Currently when aliasing a `for` loop variable with `let`, we replace the variable's old name with the new one. Since users have found this to be confusing, these changes switch to a model where the variable is available both under the original name and the new one.
Fixes#52528.
PR Close#54942
The following changes help the language service code build in g3:
* `Omit<T>` produces an index signature, so we must access the resulting properties with square bracket (because `noPropertyAccessFromIndexSignature` is on in g3).
* Explicitly export `absoluteFrom` from `packages/compiler-cli/index.ts`, since the `*` re-export is patched out in g3.
* Remove const from a few const enums, since accessing const enums across modules is not compatible with `isolatedModules` (which is on in g3).
PR Close#54726
Currently the `makeProgram` utility from `ngtsc/testing` does not use
the test host by default- optimizing for source file caching.
Additionally, the host can be updated to attempt caching of the `.d.ts`
files from `@angular/core`— whether that's fake core, or the real core-
is irrelevant. We are never caching if these changes between tests, so
correctness is guaranteed.
This commit reduces the type check test times form 80s to just 11
seconds, faster than what it was before with `fake_core`. The ngtsc
tests also run significantly faster. From 40s to 30s
PR Close#54650
This commit exposes the new `output()` API with numerous benefits:
- Symmetrical API to `input()`, `model()` etc.
- Fixed types for `EventEmitter.emit`— current `emit` method of
`EventEmitter` is broken and accepts `undefined` via `emit(value?: T)`
- Removal of RxJS specific concepts from outputs. error channels,
completion channels etc. We now have a simple consistent
interface.
- Automatic clean-up of subscribers upon directive/component destory-
when subscribed programmatically.
```ts
@Directive({..})
export class MyDir {
nameChange = output<string>(); // OutputEmitterRef<string>
onClick = output(); // OutputEmitterRef<void>
}
```
Note: RxJS custom observable cases will be handled in future commits via
explicit helpers from the interop.
PR Close#54650
This commit replaces `fake_core` with the real `@angular/core`
output. See previous commit for reasons.
Overall, this commit:
* Replaces references of `fake_core`
* Fixes tests that were testing Angular compiler detection that _would_
already be flagged by type-checking of TS directly. We keep these
tests for now, and add `@ts-ignore` to verify the Angular checks, in
case type checking is disabled in user applications- but it's worth
considering to remove these tests. Follow-up question/non-priority.
* Adds `@ts-ignore` to the tests for `defer` 1P because the property is
marked as `@internal` and now is (correctly) causing failures in the
compiler test environment.
* Fixes a couple of tests with typos, wrong properties etc that
previously weren't detected! A good sign.
PR Close#54650
Previously, the language service relied on deep imports such as `@angular/compiler/render3/...`. This is bad form, because that creates a dependency on the package's internal structure. Additionally, this is not compatible with google3.
In this PR, I replace all the deep imports with shallow imports, in some cases adding the missing symbol to the `compiler.ts` exports.
PR Close#54695
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
Currently we have two fake copies of `@angular/core` in the compiler tests which can be out of sync and cause inconsistent tests. These changes reuse a single copy instead.
PR Close#54344
Kristiyan Kostadinov