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 Angular build system recently introduced an opt-in chunk optimizer
for application builds. This is now enabled for adev production builds.
It reduces the initial chunk count from 14 to 1 JavaScript file. While
the raw initial total file size does increase by 0.75% (7.3kB), the total
estimated transfer size decreases by 8% (17.8kB). Not only does this
reduce the amount of data that must be sent over the network but it also
reduces the amount of HTTP requests that must be made by the browser.
While the injected HTML module preloads mitigate request cascades, not
needing to make the requests is even better.
PR Close#56830
In Bazel, the `CI` environment variable is not set due to its hermetic nature. As a result, caching is enabled by default, which includes Vite pre-bundling. This is unnecessary in CI environments.
In some cases, this leads to errors during CI runs when the Vite build is closed or canceled prematurely, resulting in the following errors:
```
Error: R] The build was canceled
Error: R] Terminating worker thread [plugin angular-vite-optimize-deps]
```
PR Close#57863
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
The visitor that all extended diagnostics are based on hadn't implemented the `visitIcu` method which meant that it wasn't detecting any code inside of them.
Fixes#57838.
PR Close#57845
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
Whenever the `ngc` binary is used directly to parse configurations, we
should try to respect the configured file system like we do in all other
places. Right now one spot where we escape the FS is for reading
directories to e.g. support tsconfig#includes.
This commit fixes this, implementing TypeScript's read directory method
leveraging the configured FS. The approach taken here was used for a
couple of months/years for Angular Material migrations and no issues
were found.
PR Close#57805
For component stylesheet hot module replacement scenarios, it will be necessarily to directly
encapsulate a component's stylesheet in a single operation. This currently requires the
consumer of the `encapsulateStyle` helper to use the internal Angular attribute values combined
with a find/replace over the entire stylesheet. To avoid both of these, the helper function now
has an optional second parameter which allows direct and full encapsulation of a style for a given
component when the component identifier is known.
PR Close#57809
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
