Similar to a previous fix that intended to make the JIT transforms
compatible with pre-transforms like e.g. Tsickle, we need to solve
an additional issue where the class properties are synthetic and result
in an `getSourceFile() => undefined` invocation that breaks the import
insertion, causing errors like:
```
TypeError: Cannot read properties of undefined (reading 'fileName')
```
PR Close#57262
From the internal issue on the matter:
> When using the standard Jasmine version of it promises returned by the body function are automatically awaited. The Catalyst version of it is fake-async, so awaiting the promise does not make sense; however it would be nice if Catalyst automatically flushed the promise to replicate the experience of using standard it. This would allow users to do the following:
```
it('should fail later', async () => {
await new Promise(r => setTimeout(r));
fail('failure');
});
```
> In Catalyst today the above test will pass. If this proposal to automatically flush the resulting promise were implemented it would fail.
Flushing after the tests complete has been the default behavior inside
Google since 2020. Very few tests remain that use the old behavior of
only flushing microtasks. The example above would actually fail with
`fakeAsync` due to the pending timer, but the argument still remains the
same. We might as well just flush if we're going to fail the test
anyways by throwing if there's no flush at the end.
PR Close#57137
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
This commit adds an option to specify the default value for
`queryParamsHandling` in `Router.createUrlTree` when another option is
not specified (or is `null|undefined`).
resolves#12664
PR Close#57198
This was an old feature that mapped shift + click (et al) to "clickmod". This doesn't really make sense to add to Angular, so let's remove it.
PR Close#57201
Lock file maintenance updated Terser, which impacts the bundle
optimizations being tested via the symbol golden tests.
There was a small noticable change in the symbol golden where
`withDomHydration` is now preserved, and the underlying function
that was previously detected is gone. Seemingly Terser now inlines
this function and had to preserve `withDomHydration` as the entry point.
PR Close#57205
This commit is similar to 98ed5b609e, and
makes use of the preparation work implemented there.
Similar to directives and components marked via `jit: true`, we also
need to do the same for JIT marked `@NgModule` classes. This is mostly
important for downleveling of decorators to support dependency injection
of such classes.
Inside Google3, migrating from `ts_library` to `ng_module` turns of
decorator downleveling, so the `jit: true` for NgModule's is implicitly
requesting/reliant on this transform— as expected.
PR Close#57212
Rather than leaving the timers around as no-ops, this commit updates the
logic to also attempt to clear or cancel the timers. This is helpful for
the eventual goal of running the scheduler in the `fakeAsync` zone (if
the test is running in `fakeAsync`) rather than scheduling in the root
zone and making it impossible to flush.
PR Close#57186
This creates a private option that can be used internally while we
migrate this to the default and only behavior. ~200 tests in TGP have errors
that are being swallowed (console.log) and not causing the test to fail.
We can first explicitly opt those out, flip the default internally, then
"fix" them by adding expect...toThrow.
PR Close#57153
This commit adds the `ImagePerformanceWarning` to the common bootstrap
code rather than only starting it when using `bootstrapApplication`.
PR Close#57060
This commit de-duplicates the code for bootstrapping between
`bootstrapApplication` and `bootstrapModule`. A majority of the
bootstrap code was identical between the two, with some minor
differences that can be handled with a function overload.
PR Close#57060
This commit allows configuring `NgZone` through the providers for
`bootstrapModule`. Prior to this change, developers had to configure
`NgZone` in the `BootstrapOptions`.
PR Close#57060
Fixes that we were throwing an assertion error during hydration if a `@let` declaration is used before and immediately inside of a container.
Fixes#57160.
PR Close#57173
To increase the ease of development we are moving @angular/docs into the adev directory within this repo. While
we are doing this to improve our development experience in the short term, efforts are also in place
to maintain a division between this @angular/docs (shared) code and adev itself, so that it can be extracted
back out in the future when components is ready to leverage it as well.
PR Close#57132
The behavior of `ComponentFixture` for zoneless tests was decided somewhat through guesswork, trial, and error. In addition, working on the zoneless fixture revealed oddities in the behavior of the zone-based fixture, or behaviors that we felt were counterintuitive. The most consequential difference is how change detection works: `detectChanges` goes through ApplicationRef.tick in zoneless while it is `changeDetectorRef.detectChanges` in the zone fixture.
We felt that running change detection through `ApplicationRef.tick` was important for several reasons:
* Aligning application behavior more closely with the test behavior (almost all views are attached to application ref in reality)
* Ensuring that afterRender* hooks are executed when calling `fixture.detectChanges`
* Ensuring that the change detection runs again if render hooks update state
This change, however, has some noticeable consequences that will break some tests, mostly around how errors are handled. `ApplicationRef.tick` catches errors that happen during change detection and reports them to the ErrorHandler from DI. The default error handler only logs the error to the console. This will break tests which have `expect(() => fixture.detectChanges()).toThrow()`. In addition, it allows tests to pass when there are real errors encountered during change detection.
This change ensures that errors from `ApplicationRef.tick` are rethrown
and will fail the test. We should also do a follow-up investigation to
determine whether we can/should also do this for the zone-based
`ComponentFixture`.
fixes#56977
PR Close#56993
The `inject` migration can leave some unused imports behind when it removes decorators like `@Inject`. These changes add some logic to remove them.
PR Close#57179
Makes a few optimizations in the utilities we use for dealing with imports in migrations. I didn't end up using these in the inject migration, but they should still come in handy. Includes:
1. Exiting `isReferenceToImport` early when the node being checked is an identifier and it doesn't match the identifier of the import. This saves us some type checker calls.
2. Adds the ability to pass a single string to `getImportSpecifiers`. This saves us unnecessary arrays and for loops.
PR Close#57179
Currently we use some short variable names like `t` and `r` in the generated factory functions. They can conflict with local symbols with the same names, if they're used for DI.
These changes add a `ɵ` to the generated variables to reduce the chance of conflicts.
Fixes#57168.
PR Close#57181
Updates the inject migration to unwrap the `forwardRef` call in cases like `constructor(@Inject(forwardRef(() => Foo)) foo: Foo);`, because the `forwardRef` will type the initializer to `any` and it shouldn't be necessary.
PR Close#57127
This can up in Material where we had a `constructor(@Optiona() foo: Foo | null)` which ended up producing incorrect code, because the union type was preserved.
These changes resolve the issue by picking out the first non-literal type from the union for the `inject` call.
PR Close#57127
Currently if an injected type has type arguments, we copy it over together with the type arguments to inject, because `inject()` isn't able to infer the generic properly otherwise. E.g. if there's `constructor(el: ElementRef<HTMLElement>)` we produce `inject<ElementRef<HTMLElement>>(ElementRef<HTMLElement>);`.
These changes drop the generics from the `inject()` parameter since we're overwriting the type anyway. The example from above would become `inject<ElementRef<HTMLElement>>(ElementRef);`.
PR Close#57127
Follow-up to #56961 which doesn't appear to have caught all the cases. This change moves the pre-emit untagging to `NgCompiler.prepareEmit` which seems to cover a bit more comared to `NgtscProgram.emit`.
Fixes#57135.
PR Close#57138
This reverts commit 66ffeca2de.
It looks like nuxt encountered the same issue with scrolling when
waiting for Vue's `nextTick`, which is a microtask. This would have
similar timing to ZoneJS's rendering in the microtask queue. This
reverts to a `setTimeout` alone, though recreates the problem in #53985.
This was also mentioned in one of the comments in the Nuxt issue and the
solution would be `rAF`.
In order to address #53985, we'd likely want to use the `race(rAF, setTimeout)`
that we use in the zoneless and coalescing schedulers. This would have effectively the same timing as
the `afterNextRender` implementation here with zoneless, but quite
different timing to `afterNextRender` with ZoneJS.
fixes#57109
PR Close#57115
Updates the import manager to allow for a specific alias to be passed in. This is a prerequisite for switching schematics to the new import manager.
Note that passing in an alias disables identifier conflict resolution in order to avoid rewriting the alias that was passed in explicitly. For now this is fine since we have a very narrow use case for it, but we may want to revisit it in the future.
PR Close#57096
This commit adds golden tests for the signal input migration, along with
a tool to execute and automatically test the migration via the batch
mode, treating a single file as compilation unit.
PR Close#57082
This commit adds the batching logic helpers for running the signal
migration as a sharded/parallel action in Google3 and potentially
externally. The helpers are the main entry points for go/tsunami.
PR Close#57082
Adds the migration phase for migrating inputs and references. Thise
phase may execute as the third step when batching.
The migration is intentionally split into three phases:
1. Extract and analyze
2. Inheritance merge / merge of metadata
3. Migrate
This allows us to batch the migration in Google3, or for large projects,
merge metadata, and then batch-execute migration for computation of
replacements. This is compatible with Google's LSC tsunami tool.
PR Close#57082
E.g. detects `spyOn(myComp, 'input')`. This is problematic
as `input` no longer provides access to the raw value via property
access, but via a getter. The `spyOn` would be effictively a noop,
causing tests to fail. We skip such inputs for safety right now.
Similarly, we have an advisor for correcting type safety loss
with `.componentInstance` in unit tests. This is a common pattern
but is typed in Angular core as `any`. This breaks resolution of
references and we accidentally miss those. This advisor mitigates that.
PR Close#57082
This commit adds the logic for detecting and capturing references to
Angular `@Input`s. Those references may be migrated to unwrap signals
as part of the migration; or are refactored into temporary variables.
This commit detects and captures:
- host bindings references
- template references
- TypeScript references
PR Close#57082
This commit adds logic for AST traversing Angular HTML templates and
detecting references to Angular `@Input`s that may be migrated.
In addition, the expression visitor logic is built in a generic way so
that it can also be used for finding references in host binding
expressions— where no type check block information is available.
PR Close#57082
This commit includes the initial logic for converting `@Input()` to
`input`. The logic is not fully polished in terms of what use-cases
and patterns we want to generate, but it's working pretty stable
with testing in Angular Material and some g3 targets.
We may improve this and e.g. generate the `input()` shorthand in a
couple of cases.
The commit also includes some related helpers/parts that are needed
for the migration phases.
Notably the conversion phase is split up into preparation and migration.
That is necessary because as part of analysing we already try to
prepare to see if it's "possible". This is necessary for the global
metadata analysis, so that we can know that certain references are
incompatible across compilation units (e.g. when running as a batch).
PR Close#57082
This commit adds the initial set of helpers and registries for tracking
inputs discovered in the signal input migration.
A few short summary notes:
- Every input has an unique key. This key is used for global analysis
that may be performed when the migration is executed on a per
individual unit basis in Google3 via e.g. go/tsunami — The keys allow
us to build a combined global metadata for e.g. references or figuring
out which inputs are incompatible or not.
- A known input may be _any_ input in an compilation unit/ the program.
E.g. even inputs from `d.ts`. We keep track of these inputs so that we
can later figure out if a reference `ts.Identifier` points to any of
those. In addition it allows us to attach incompatibility metadata to
those. I.e. incompatible for migration because "something writes to
the input".
PR Close#57082
