This commit marks the contentChild, contentChildren, viewChild
and viewChildren APIs (along with any associated APIs) as stable
and thus exits the dev preview
phase for those APIs.
PR Close#57921
The `SharedStylesHost` class has been refactored to both reduce the runtime
code size and also modernize some of the code structures. The class is also
adjusted to better support reuse via subclassing or other reuses in the future.
Additional comments have been added to improve readability as well.
The code reduction in a prerelease newly generated Angular CLI application
for production is ~410 bytes.
Before:
```
Initial chunk files | Names | Raw size | Estimated transfer size
main-GOQKBZBZ.js | main | 208.67 kB | 56.41 kB
polyfills-FFHMD2TL.js | polyfills | 34.52 kB | 11.28 kB
styles-5INURTSO.css | styles | 0 bytes | 0 bytes
| Initial total | 243.19 kB | 67.69 kB
```
After:
```
Initial chunk files | Names | Raw size | Estimated transfer size
main-CRTDDKPH.js | main | 208.26 kB | 56.32 kB
polyfills-FFHMD2TL.js | polyfills | 34.52 kB | 11.28 kB
styles-5INURTSO.css | styles | 0 bytes | 0 bytes
| Initial total | 242.78 kB | 67.61 kB
```
PR Close#57834
When running a migration, tsurge creates a TS program from the tsconfig files found.
This can result in a 18003 error when no files are found (based on the includes/files of the config).
For example, the signal input migration throws in a CLI project that has no spec files:
```
ng g @angular/core:signal-inputs --defaults
Tsconfig could not be parsed or is invalid:
No inputs were found in config file '/tsconfig.spec.json'. Specified 'include' paths were '["src/**/*.spec.ts","src/**/*.d.ts"]' and 'exclude' paths were '["/out-tsc/spec"]'.
```
A similar issue has already been raised in the CDK migration (see https://github.com/angular/components/issues/27055).
This was solved in the CDK (credits to @crisbeto) by ignoring the 18003 error (see 9c1112d408361a47c98dfd470b8e990cbd1753db).
This PR does the same in tsurge.
PR Close#57899
This commit promotes the `ExperimentalPendingTasks` service from
experimental to developer preview and includes a migration schematic for
the rename.
BREAKING CHANGE: `ExperimentalPendingTasks` has been renamed to
`PendingTasks`.
PR Close#57533
The compiler and its file system implementation expects `fs.exists` to
return `true` even for directories. This caused issues with the TSConfig
resolution as `/` was looked up.
We fix this by making use of `stat` which is equally expensive to
`tree.exists`. The devkit tree's don't expose directory existance checks
out of the box.
Fixes#57887.
PR Close#57897
The batch test (not running on CI due to memory/resource constraints) currently fails
after refactorings we did recently. This commit fixes that there were
two different instances of `sourceFiles string[]`.
PR Close#57883
Instead of running inheritance checking for analyze and migration phases
(in batch mode), we can run once and create a mini-graph in the
compilation unit data. This can then improve lookups and propagation of
incompatibilities.
This commit fixes an issue where a class is chained between three
isolated units and members are overriden. Currently this pattern would
not be checked properly and e.g. an incompatibility of the superclass
would not propagate to derived class, or deeper.
PR Close#57883
This reduces the bytes of the merged compilation unit data, so that we
don't have to transer gigabytes of data to every batch worker. This
reduces quota and helps with reliablity of the migration in 1P.
The references metadata was never needed across units, but an initial
idea to e.g. allow for issuing of CLs based on a graph that we build
after changes computation
PR Close#57883
Currently we support filtering files outside of the project, or source
files via `shouldMigrateInput` option. This works well, but we can
smartly skip inputs in batch migrations if we never saw a source
declaration.
This is an improvement in G3 where we cannot simply limit the migration
to a given directory, because we may include build targets from various
places. E.g. via reverse dependency tracking— so this fixes the issue
naturally.
Notably, an explicit filter would improve reference lookups because we
wouldn't consider the input when determining potential references. That
is because we would know beforehand that those inputs in the `.d.ts`
cannot be migrated inputs— and therefore references with names of the
input would never be verified via expensive type checking.
This is fine for G3 though, and there is no way around this. This is a
slow performance overhead; mostly releveant for VSCode integration.
PR Close#57883
This commit flips the flag that was added in 4e890cc, putting the new effect
timing into... effect :)
BREAKING CHANGE:
Generally this PR has two implications:
* effects which are triggered outside of change detection run as part of
the change detection process instead of as a microtask. Depending on the
specifics of application/test setup, this can result in them executing
earlier or later (or requiring additional test steps to trigger; see below
examples).
* effects which are triggered during change detection (e.g. by input
signals) run _earlier_, before the component's template.
We've seen a few common failure cases:
* Tests which used to rely on the `Promise` timing of effects now need to
`await whenStable()` or call `.detectChanges()` in order for effects to
run.
* Tests which use faked clocks may need to fast-forward/flush the clock to
cause effects to run.
* `effect()`s triggered during CD could rely on the application being fully
rendered (for example, they could easily read computed styles, etc). With
the change, they run before the component's updates and can get incorrect
answers. The recent `afterRenderEffect()` API is a natural replacement for
this style of effect.
* `effect()`s which synchronize with the forms system are particularly
timing-sensitive and might need to adjust their initialization timing.
Fixes#55311Fixes#55808Fixes#55644Fixes#56863
PR Close#57874
The original effect design for Angular had one "bucket" of effects, which
are scheduled on the microtask queue. This approach got us pretty far, but
as developers have built more complex reactive systems, we've hit the
limitations of this design.
This commit changes the nature of effects significantly. In particular,
effects created in components have a completely new scheduling system, which
executes them as a part of the change detection cycle. This results in
behavior similar to that of nested effects in other reactive frameworks. The
scheduling behavior here uses the "mark for traversal" flag
(`HasChildViewsToRefresh`). This has really nice behavior:
* if the component is dirty already, effects run following preorder hooks
(ngOnInit, etc).
* if the component isn't dirty, it doesn't get change detected only because
of the dirty effect.
This is not a breaking change, since `effect()` is in developer preview (and
it remains so).
As a part of this redesigned `effect()` behavior, the `allowSignalWrites`
flag was removed. Effects no longer prohibit writing to signals at all. This
decision was taken in response to feedback / observations of usage patterns,
which showed the benefit of the restriction did not justify the DX cost.
The new effect timing is not yet enabled - a future PR will flip the flag.
PR Close#56501
Notably the inheritance checking is less complete as the one in the
input migration. That is because we can't efficiently determine query
fields in the analyze phase of compilation units. Unless we aggresively
consider every field of decorated classes as queries and complexify
the merged metadata significantly, we can't reliably check for cases
where a class is incompatible for migration because it overrides a
member from a class that is in a different compilation unit.
This is an acceptable limitation though (maybe for now), as worst case,
we would migrate the class and the other compilation unit would simply
break. Not ideal, but migrations are impossible to be 100% correct in
general— so not a surprise.
In the future, we may find ways to identify queries more reliably in
analyze phase already. e.g. if the compiler were to include this
metadata in the `.d.ts`, or if we decide to simply add this to the
metadata, accepting potential significant HDD increase.
PR Close#57854
Before this commit, `@let` decleration with an array where mistaken for a component in the lView and throwing an unexpected error.
This commit fixes this.
PR Close#57816
Optional operations that don't run in the actual application compilation
would then cause fatal diagnostic errors breaking the compiler
initialization at runtime.
We should try to keep the migration as close as possible to the
application build.
PR Close#57835
This commit prepares us for sharing the problematic pattern detection,
or inheritance checking. E.g. if a class is manually instantiated, using
certain APIs may not be considered safe. This logic will be shared in
the following commit.
PR Close#57835
Finalizes compiler implementation of the new `hydrate` triggers by:
* Reworking the logic that was depending on the `hydrateSpan` to distinguish hydrate triggers from non-hydrate triggers.
* Fixing that the `hydrate when` trigger didn't have a `hydrateSpan`.
* Adding an error if a parameter is passed into a `hydrate` trigger.
* Add an error if other `hydrate` triggers are used with `hydrate never`.
* Replacing the `prefetch` and `hydrate` flags in the template pipeline with a `modifiers` field.
* Fixing an error that was being thrown when reifying `hydrate` triggers in the pipeline.
* Adding quick info support for the `hydrate` keyword in the language service.
* Adding some tests for the new logic.
PR Close#57831
Introduces a new `ng generate` schematic for migration `@Input()`
declarations to signal inputs.
This migration is the same that is also integrated into the
VSCode extension.
Note: In a follow-up the documentation for this will be improved, and a
flag to report reasons on why certain inputs weren't migrated, is added.
PR Close#57805
This commit marks the input, output and model APIs as stable
(along with the associated APIs) and thus exits the dev preview
phase for those APIs.
PR Close#57804
This helper method is simply a convenience function that reduces some
boilerplate with manually adding and removing a task around some
asynchronous function.
PR Close#56546
The query migration will now fully re-use the reference resolution and
migration logic from the input migration to reliably migrate references
to the new signal properties, supporing control flow outsourcing etc.
PR Close#57777
Commonly when testing Tsurge migrations, we need to diff text content of
files. This commit adds a colored diff helper that makes writing tests
much easier.
PR Close#57777
Dedenting the smallest leading whitespace is useful for conveniently
testing the output of a migration. This commit includes the helper in
Tsurge.
PR Close#57777
This commit introduces an overload for `input` to accept `undefined` as initial value if only
options are needed to be provided, inferring an input of type `T|undefined`. Prior to this change,
the type argument as specified needed to include `|undefined` explicitly even though that isn't
necessary when passing options isn't needed.
Relates to #53909
PR Close#57621
The reference migration code of the signal input migration should be
re-usable as the queries migration needs the exact same.
This builds on top of the shared reference resolution logic from
previous commits. Similarly this commit introduces a small "host" for
providing necessary configurable information about what references
should be migrated; supporting e.g. "input incompatibilities".
This is important as e.g. queries may also be incompatible for migration
and references to such, should not be migrated.
PR Close#57766
Allows us to re-use the reference resolution that works within TS code,
Angular templates, or host bindings. This is helpful for queries
migration which also needs to migrate many references, or allows use in
the output migration.
This is achieved by introducing an abstraction of the "known inputs"
registry we have already, but making it more generic to work with _any_
class fields. Known inputs can then implement/extend this. Queries
similarly.
The "known fields" construct gives insight on field unique IDs etc. This
is then used by the reference resolution to determine if it's a
reference that needs to be captured.
We may move all of this code to Tsurge eventually; depending on how
useful it is. We'll discuss.
PR Close#57766
This change uses the outputToObservable utility function to
convert migrated outputs to Observables. This happens only
in test files as it is a common practice to use RxJS to listen
to events raised by the component under test.
PR Close#57691
Instead of traversing the same paths multiple times, we should avoid
this extra work and optimize. This solves some issues in super large
files with extremely complex flow graphs. E.g. large `ngOnChanges`
functions in Pantheon.
For an example of a flow graph where it doesn't make sense to re-visit
nodes that have multiple incoming edges, see this internal screenshot:
https://screenshot.googleplex.com/6ub4e5e5gbzJAvH
PR Close#57719
