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
When on a certain width, the tab-bar width glitch back-and-forth and forcing the 2 other buttons to reduce their width. This glitches appeared when we introduced that 2nd button.
fixes#57143
PR Close#57172
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
Dev-infra recently upgraded to Renovate version 38. This update causes `matchDepPatterns` to only accept RegExp. Since we require a glob pattern, we will now use `matchPackageNames`, which supports glob patterns and is already used in the configuration.
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
The test was broken because multiple errors happen and the last error would be the displayed message.
However, in this case, those errors happen because the initial one already terminated the container
so the follow-up errors are a result of the service being in an unexpected state
PR Close#57104
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
Andrew Scott