Currently during the module pruning stage of the standalone migration we assume that any leftover modules which only have `imports` and `exports` can safely be removed. That can be incorrect for the cases where some parts of the app were converted to standalone outside of the migration.
These changes update the logic so that such modules are replaced with the `exports` which are used within the specific component.
Fixes#51420.
PR Close#57684
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
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
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
This commit changes the structure of the API extraction files to include all symbols used inside a package.
The structure is a `Map`, Symbol => package
eg: 'ApplicationRef' => '@angular/core'
PR Close#57346
This allows us to bundle e.g. the signal input migration into
language-service without duplicating code. Rollup with Bazel may end up
duplicating because it isn't able to associate the local sources with
the linked modules from `node_modules/@angular/compiler-cli`.
PR Close#57214
(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
