This commit updates the `package.json` of the zone.js package.

PR Close #52385

Fix some typos such as `boostrap`, `propery` and more, both in
documentation and in code (comments, identifiers).

PR Close #52249

PR Close #52297

This commit covers several changes:
 - routing enabled by default
 - standalone by default

PR Close #52293

Signals are out of dev preview now.

PR Close #52375

This adds jessicajaniuk and AndrewKushnir to the fw-migrations reviewers list.

PR Close #52378

This updates language to clarify exactly how prefetch works in a defer block configuration.

PR Close #52379

PR Close #52374

fix(router): `RouterTestingHarness` should throw if a component is expected but navigation fails (#52357)

The `RouterTestingHarness` should throw an error if the call to `navigateByUrl`
expects a component to be activated but the navigation failed.

fixes #52344

PR Close #52357

This is needed so that the providers configured on platform creation are picked up by the injector profiler.

PR Close #52365

Previously, because the platform injector does not have a provider container, this API would fail. Now, we account for this case specifically by returning the found providers immediately, without trying to calculate their importpaths.

Also previously, in the case where a boostrapped standalone component did not import any feature modules, the environment injector connected to that bootstrapped component would be the root injector configured by `bootstrapApplication`. This injector is configured through a `providers` array instead of an `imports` array, and also does not have a provider container. Similarly to the platform case, we account this for this by returning the found providers immediately if there is no provider container for our standalone component.

PR Close #52365

Previously this case was missed by the default framework injector profiler. Now in ngDevMode this event emits correctly when a service is configured with `providedIn`. This includes the case where injection tokens are configured with a `providedIn`.

This commit also includes unit tests for this new case in the injector profiler.

PR Close #52365

PR Close #52229

This adds the initial API reference documentation for the new defer blocks.

PR Close #52336

Angular recently gained a local compilation mode (see commit
345dd6d8). This is intended to be used
with the TypeScript compiler option isolatedModules, which bans imports
of const enums.

This changes all const enums tagged with @publicApi to regular enums.

Fixes #46240

PR Close #51670

This updates the code to handle switches more elegantly in line with how the other blocks are handled. This allows nesting to be handled just like other blocks.

PR Close #52358

PR Close #52323

fixes broken code snippet for standalone application using APP_INITIALIZER

PR Close #52354

PR Close #52352

PR Close #52356

`globalThis` global property contains the global `this` value, which is usually akin to the global object. This is needed for better compatibility with CloudFlare workers were global nor window are defined as globals.

PR Close #52367

Use nullish coalescing.

PR Close #52368

Use `globalThis` global property contains the global this value, which is usually akin to the global object.

PR Close #52368

This commit runs change detection in a loop while there are still dirty
views to be refreshed in the tree. At the moment, this only applies to
transplanted views but will also apply to views with changed signals.

fixes angular#49801

PR Close #51854

Fixes that the control flow migration was only processing top-level classes. Nested classes could come up during unit tests.

PR Close #52309

Fixes that the block entities migration was only processing top-level classes. Nested classes could come up during unit tests.

PR Close #52309

This commit reduces the property size in the http transfer cache to reduce the page payload.

Before
```html
<script id="ng-state" type="application/json">
{
  "4155228514": {
    "body": "....",
    "headers": {},
    "status": 200,
    "statusText": "OK",
    "url": "http://foo.com/assets/media.json",
    "responseType": "json"
  },
}
</script>
```

Now
```html
<script id="ng-state" type="application/json">
{
  "4155228514": {
    "b": "....",
    "h": {},
    "s": 200,
    "st": "OK",
    "u": "http://foo.com/assets/media.json",
    "rt": "json"
  },
}
</script>
```

PR Close #52347

See associated pull request for more information.

PR Close #52353

When migrating an ng-template later on in a file, the migrationResult was not being reset to zero and causing offsets to be double applied due to ng-template nodes being included in the migration loop.

PR Close #52355

Previously, we would emit *two* pipe creation instructions for each pipe in a switch case. This is because we were visiting both the transformed and raw versions of the pipe bindings.

Now, we clear the raw case expressions array after generating the transformed test expression.

Also, we introduce some new goldens, because our pipe creation order is harmlessly different.

PR Close #52289

The `projection` op should map onto the entire corresponding `ng-content`.

PR Close #52289

We roughly attempt to match TemplateDefinitionBuilder's pipe creation order, by placing pipe creation instructions after their target elements. However, we cannot fully emulate the "inside-out" ordering TemplateDefinitionBuilder uses when multiple pipes apply to one element, because TemplateDefinitionBuilder creates the pipes as expressions are visited, from the leaves up. Our order is perfectly adequate though.

We also add a non-compatibility-mode ordering, which just appends them to the end of the create block. This is better because it allows for more chaining opportunities.

PR Close #52289

refactor(compiler): Fix a special case involving var counting for singleton `propertyInterpolate` (#52289)

Singleton property interpolation instructions consume only one variable, but are still emitted as an interpolation instruction (they cannot be collapsed because `propertyInterpolate` implicitly stringifies its argument.)

PR Close #52289

We were incorrectly emiting a extracted constant pool index for the final argument of the projection instruction. It actually takes an array literal.

(N.B.: This means we re-create the array every time! We should probably modify the runtime to use a const index for this.)

Additionally, we alter the projection op to not extend the element op base type.

PR Close #52289

The correct order of attributes and properties is:

1. Interpolated properties
2. Interpolated attributes
3. Non-interpolated properties
4. Non-interpolated attributes

This includes an additional nuance: singleton attribute interpolations, such as `[attr.foo]="{{bar}}"`, will be "collaped" into a simple `attribute` instruction. However, this is *not* the case for singleton property interpolations! The ordering phase must take this nuance into account to match the TemplateDefinitionBuilder order.

After the project lands, it might be nice to also collapse singleton property interpolations.

PR Close #52289

Previously, we ran the ordering phase near the end of the compilation. However, this meant that phases like slot assignment and variable offset assignment would happen first, and then the nice, monotonically-increasing orders would be scrambled by the reordering.

It's much more intelligible to order first, and then perform these assignments. However, to make this happen, some modifications to the ordering phase are required. In particular, we can no longer rely on `advance` instructions to break up orderable groups.

PR Close #52289

Many instructions consume variable slots, which are used to persist data between update runs. For top-level instructions, the offset into the variable data array is implicitly advanced, because those instructions always run.

However, instructions in non-top-level expressions cannot be assumed to run every time, because they might be conditionally executed. Therefore, they cannot implicitly advance the offset into the variable data, and must be given an explicitly assigned variable offset.

TemplateDefinitionBuilder assigned offsets top-to-bottom for all instructions *except* pure functions. Pure functions would be assigned offsets lazily, on a second pass.

Template Pipeline can now imitate this behavior, when in compatibility mode: pure functions are assigned offsets on a second pass.

This also makes the "variadic var offsets" phase unnecessary -- the new approach is more general and correct.

PR Close #52289

Previously, inside an event listener, template pipeline would always save the context from restoring a view, e.g.

```
const restored_ctx = r0.ɵɵrestoreView(s);
```

This is usually correct! However, consider the case of a listener in the template's root view. The appropriate context will already be available via closure capture, and we can just use it (as `ctx`).

Now, the context resolution phase understands that we don't need to use the restored view's saved context if we would have access to it by closure.

Note: we also create a new golden, because the const array is in a harmlessly different order.

PR Close #52289