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
Currently the import manager always add a space after the import clause
brace. We should only do this if the existing import did the same.
PR Close#57672
Currently whenever we apply the import manager changes in migations, we
leave the decision of multi-line or single-line to the TS printer.
This works, but in practice can cause signficiant file jumps/changes if
there are large imports that aren't wrapped for example, or the other
way around. We should try to be minimal here and preserve the existing
formatting, assuming that a multi-line import remains multi-line, while
a single-line import remains single-line if it already had many items in
a single line, intentionally.
PR Close#57672
Whenever the signal input migration runs in VSCode, other inputs are
marked as incompatible via the config. Best effort mode currently skips
those incompatibilities and still migrates them. This is incorrect as
the config intends to skip those inputs, regardless of best effort mode.
PR Close#57672
The migration took a type from the directive handler metadata, and
inserted it into a synthetic node for the new input() call. This works
perfectly fine, but in some cases, I saw some `T:VAE` comments attached
🤯 These are from the type checker which attached
synthetic comments to the exact same node.
PR Close#57672
Whenever we migrate object expansion patterns, we may need a temporary
variable to generate a construct like:
```ts
const {bla: blaValue} = this;
const bla = blaValue();
```
We should instead use `blaInput` as the name for the temporary
variable. For narrowing constants, `blaValue` is correct, but here
it's an actual reference to the input / signal.
PR Close#57659
With the preparation work from previous commits, we are able to reduce
analysis time of the migration from e.g. whole Material repo 7seconds to
0.1seconds when the migration is invoked via the VSCode extension.
This is possible because we can avoid many expensive type checking
lookups if we know what inputs are actually migrated. We do this by
adding some naive pre-check to see if identifiers are possibly pointing
to a migrated input.
This is possible now because we no longer migrate aliased identifiers
for object expansion, but instead migrate directly at object
expansion declaration. This allows us to assume that all possible
references to inputs must go through identifiers that are named like
the original input class field name.
PR Close#57659
Instead of printing the enum name as the reason why migration did not
complete, we should print some human-readable descriptions.
This commit implements this. This logic may also be useful for the
devkit comment generation, or CLI usage.
In addition, we expose another VSCode refactoring to try via best effort
mode. There is no way for prompting, or adding multiple actions for the
same refactoring, so we expose a new refactoring.
PR Close#57659
Whenever the signal migration discovers multiple references in the same
control flow container, it assumes narrowing and wants to preserve this
functionality. It does this by introducing temporary variables.
This works fine, but currently there is an edge case with arrow
functions, as those can also turn into blocks, but aren't considered as
such in the current code. This commit fixes this, so that arrow
functions will be converted to be block-based if necessary.
PR Close#57659
This commits extends the decorator-based output migration
to replace .next usage (not supported with the output function)
with .emit (supported in both decorator-based and function based
outputs).
PR Close#57654
Angular 18 introduced fallback content for <ng-content>. This commit updates the docs of content projection guide to contain fallback content for <ng-content>.
PR Close angular#57083
PR Close#57513
Adds a new diagnostic that will report cases where a declaration is in the `imports` array, but isn't being used anywhere. The diagnostic is reported as a warning by default and can be controlled using the following option in the tsconfig:
```
{
"angularCompilerOptions": {
"extendedDiagnostics": {
"checks": {
"unusedStandaloneImports": "suppress"
}
}
}
}
```
**Note:** I'll look into a codefix for the language service in a follow-up.
Fixes#46766.
PR Close#57605
Currently we detect element bindings as normal references and inside
usages we simply unwrap its usages. This works, but breaks in situations
like the following:
- When the expressions are narrowed. Narrowing analysis does not support
aliased inputs. E.g. `const {myInput: alias} = this`. We could add
this, but it would complexify the logic.
- When binding patterns deeply access value properties directly. E.g.
`const {myInput: {value}} = this;`
In addition, the current approach requires us to understand that aliases
may point to inputs. This means we need to check all identifiers if they
point to Angular inputs. We could optimize this, but it's much easier if
we can simply assume that we only need to "verify" identifiers that have
names of "known inputs". This would significantly speed up turnaround in
the language service integration.
In addition, it would be more _correct_, semantically to directly access
the value of the input at object expansion, versus later.
PR Close#57645
Adds logic to capture performance timings when resolving input
references. This is useful for debugging and improving integration in
the VSCode extension.
PR Close#57645
Moves the rather complicated reference migration logic for the input
migration into a separate method. This cleans up the logic and makes way
for an additional complexity with regards to element bindings.
PR Close#57645
This commit shares the logic for looking up a property access, using
`ts.Type` information. This is helpful in case where no linked TS
symbols are available; e.g. templates in test files without TCB.
This helper will be useful for handling object expansion in the signal
input migration; resolving references like `const {x} = this`.
PR Close#57645
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
Implement the `afterRenderEffect` primitive, which creates effect(s) that
run as part of Angular's `afterRender` sequence. `afterRenderEffect` is a
useful primitive for expressing DOM operations in a declarative, reactive
way.
The API itself mirrors `afterRender` and `afterNextRender` with one big
difference: values are propagated from phase to phase as signals instead of
as plain values. As a result, later phases may not need to execute if the
values returned by earlier phases do not change.
PR Close#57549
Previously Elements was assuming that every output was an RxJS `Subject` and
supports `.pipe()`. This is not true for `output()`-based outputs which
have `.subscribe()` but not `.pipe()`. This commit fixes such outputs by
using a `new Observable` instead of `map` to forward outputs.
PR Close#57535
Replaces esbuild with Rollup for bundling schematics to support code splitting, as esbuild does not handle code splitting when targeting CommonJS modules.
**Before:**
```
du -sh dist/bin/packages/core/npm_package/schematics
7.7M dist/bin/packages/core/npm_package/schematics
```
**After:**
```
du -sh dist/bin/packages/core/npm_package/schematics
3.1M dist/bin/packages/core/npm_package/schematics
```
PR Close#57602
This commit updates the public API for pending tasks to schedule an
application tick, effectively making the stability async when the last
task is removed.
PR Close#57570
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
Sometimes `--strictPropertyInitialization` is not enabled, while strict
null checks is enabled. In those cases, `undefined` cannot be used as
initial value with `input()`, nor can we expand the type of the input.
We can migrate those instances to `undefined!` to preserve the original
semantics and behavior. In addition, in the future we may leave a TODO
or we may consider skipping migration of such inputs.
PR Close#57629
