PR Close #44032

The `NgComponentTemplateVisitor` helper was always referring back to the original source file on disk
rather than the virtual file in the migration. This meant that some template migrations could attempt
to modify the template multiple times resulting in invalid output.

As an example the `migration-v13-router-link-empty-expression` migrates the following template:

```
<div [routerLink]></div>
```

to

```
<div [routerLink]="[]"></div>
```

But if the template was referenced multiple times in the program, such as when the component was
referenced in the source and test entry-points, the migration would result in things like:

```
<div [routerLink]="[]"="[]"></div>
```

Fixes #44005.

PR Close #44013

Previously, when parsing code for templates to migrate, CRLF characters were converted to just LF.
This meant that the source-spans being used to overwrite the template strings in the original source code were out of sync with the positions identified in the parsed templates.

This commit fixes this by parsing the raw text of the template taken from the source code instead of processed string contents.

Fixes #44005

PR Close #44013

These tests had been disabled when we initially disabled ViewEngine.
The tests appear to run fine despite this, so we can re-enable them.

PR Close #44013

PR Close #44011

This commit adds the Angular Package Format to AIO. Previously this document
was updated and versioned in Google Docs.

The document is also updated for the Angular Package Format version 13.

PR Close #43987

Update content per feedback from previous PR.

PR Close #44009

PR Close #43986

Revert "refactor(router): restore history in a consistent way on canceled navigations (#43651)" (#44006)

This reverts commit a268c447.

Causes failures in internal team's code. The failures likely relate to
attempting to manually update private Router state tracking properties,
which this change would have affected.

PR Close #44006

Update left-nav toc.

PR Close #43964

Add link for RFC. Clean up markdown formatting.

PR Close #43964

Update content per feedback in tech review.

PR Close #43964

Update release note for version 13.

PR Close #43964

Add redirect test for new latest version topic.

PR Close #43964

docs: add links to additional information.

PR Close #43964

Remove content for previous latest version.

PR Close #43964

Update content for AngularJS to Angular migration.  Add note to manually create UMD bundles.

PR Close #43964

Update content for library use.

PR Close #43964

Add the update to latest version content for version 13.  Add redirect for latest version content.  Update toc for later version content.

PR Close #43964

This fixes an issue on Safari which caused the text to be pushed down when blurring out of the search input field. The root cause of the problem appears to be that previously the computed line height was that of 32px, which caused a shift in content.

Closes #43935

PR Close #43983

Update the note for hierarchy of locale identifiers.

PR Close #43979

Remove redundant link.

PR Close #43979

This commit adds `ViewRef` to private exports, so it can be reused in internal packages.

The `ViewRef` symbol remains *private* and should not be referenced directly.

PR Close #43978

Previously, there were two ways to disable view transition animations in
`DocViewerComponent`: Using a `.no-animations` CSS class on the
`<aio-doc-viewer>` element and setting the static
`DocViewerComponent.animationsEnabled` property to `false`. The latter
was only used to disable animations for testing purposes.

With the recent introduction of `AppComponent.reducedMotion`, there is
now an easy way to disable animations in tests using the
`.no-animations` class (which is applied by `AppComponent` based on the
value of `AppComponent.reducedMotion`). Therefore, it is no longer
necessary to have `DocViewerComponent.animationEnabled`.

This commit removes the now obsolete `animationsEnalbed` property.

PR Close #43977

Make the app easier to use for people with motion sensitivities by
disabling several animations (esp. ones involving moving things around)
when the user prefers reduced motion. The user's preference is detected
using the [prefers-reduced-motion][1] CSS media feature.

Disabled animations include:
- View fade in/out transitions.
- Sidenav open/close animations.
- Top-menu color and size changes.
- Contributor cards flip animations.

For more details on using `prefers-reduced-motion` and disabling
Angular animations see:
- [Designing with reduced motion for motion sensitivities][2]
- [Disabling Angular animations at runtime][3]

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion
[2]: https://www.smashingmagazine.com/2020/09/design-reduced-motion-sensitivities/
[3]: https://dev.to/this-is-angular/disabling-angular-animations-at-runtime-9a6

PR Close #43977

This test has been removed as since the elements schematic has been removed in a previous commit.

PR Close #43975

The elements package doesn't use `@angular/platform-browser` therefore this is not needed.

PR Close #43975

This schematic is no longer needed since all the [browsers](https://angular.io/guide/browser-support) that Angular supports `CustomElementRegistry` APIs.

Side note: `document-register-element` has been deprecated in favor of `@ungap/custom-element`

PR Close #43975

This section was outdated since now all CLI projects are es2015+ and don't require the polyfill since legacy browsers are no longer supported.

PR Close #43975

All the [browsers](https://angular.io/guide/browser-support) that Angular supports `CustomElementRegistry` APIs

PR Close #43975

PR Close #43895

Previously, the master branch was only deployed to the
`next-angular-io-site` Firebase site, which is connected to the
`next.angular.io` domain. However, if the master major version was
higher than the stable major version (or the RC major version in case
there was an active RC), we also had to manually configure (via the
Firebase console and/or DNS records) the `v<X>.angular.io` domain to
redirect to `next.angular.io`. Then, once `<X>` became the new stable or
RC version, we had to manually remove the redirect (to let
`v<X>.angular.io` be redirected to `angular.io` or `rc.angular.io`).

This commit is part of a new process that reduces the manual steps as
follows (the steps below only apply when the master major version is
higher than the current stable and RC (if applicable)):
- A `v<X>-angular-io-site` Firebase site will be created as soon as the
  version in the `master` branch's `package.json` is updated to a new
  major.
- The `v<X>.angular.io` domain will be connected to that new Firebase
  site.
- When deploying from the master branch, we will deploy to both
  `next-angular-io-site` and `v<X>-angular-io-site`. In addition, the
  deployment to `v<X>-angular-io-site` will update the Firebase config
  file to redirect to `next.angular.io`.
- When the master version becomes the new stable/RC, we will start
  deploying to `v<X>-angular-io-site` from the stable/RC branch, which
  will update the Firebase config to stop redirecting to
  `next.angular.io` and redirect to `(rc.)angular.io` instead (without
  requiring changes in the Firebase console or DNS).

PR Close #43963

Previously, (when there was an active RC) the RC branch was only
deployed to the `rc-angular-io-site` Firebase site, which is connected
to the `rc.angular.io` domain. However, if the RC major version was
higher than the stable major version, we also had to manually configure
(via the Firebase console and/or DNS records) the `v<X>.angular.io`
domain to redirect to `rc.angular.io`. Then, once `<X>` became the new
stable version, we had to manually remove the redirect (to let
`v<X>.angular.io` be redirected to `angular.io`).

This commit is part of a new process that reduces the manual steps as
follows (the steps below only apply to RC versions that have a higher
major version than the current stable):
- A `v<X>-angular-io-site` Firebase site will be created for the new RC
  version.
- The `v<X>.angular.io` domain will be connected to that new Firebase
  site.
- When deploying from the RC branch, we will deploy to both
  `rc-angular-io-site` and `v<X>-angular-io-site`. In addition, the
  deployment to `v<X>-angular-io-site` will update the Firebase config
  file to redirect to `rc.angular.io`.
- When the RC version becomes the new stable, we will start deploying to
  `v<X>-angular-io-site` from the stable branch, which will update the
  Firebase config to stop redirecting to `rc.angular.io` and redirect to
  `angular.io` instead (without requiring changes in the Firebase
  console or DNS).

PR Close #43963

Previously, the stable branch was always deployed to the
`v<X>-angular-io-site` Firebase site, which was connected to the
`angular.io` domain. Whenever a new major version was released (and
became the new stable version), the `angular.io` domain had to be
disconnected from the previous Firebase site and be connected to the new
`v<Y>-angular-io-site` Firebase site. This was a manual process that
involved making changes in the Firebase console and the DNS records.

This commit is part of a new process that reduces the manual steps as
follows:
- A new `stable-angular-io-site` Firebase site is created.
- The `angular.io` domain will be connected to that new Firebase site.
- When deploying from the stable branch, we will deploy to both
  `stable-angular-io-site` and `v<X>-angular-io-site`. In addition, the
  deployment to `v<X>-angular-io-site` will update the Firebase config
  file to redirect to `angular.io`.
- When a new major version is released, we will start deploying from the
  new stable branch to `stable-angular-io-site`, but there will be no
  need to connect/disconnect the `angular.io` domain. Also,
  `v<X>.angular.io` will stop redirecting to `angular.io` by means of
  updating the Firebase config file (without requiring changes in the
  Firebase console or DNS).

PR Close #43963

Add `deploy-to-firebase` post-deploy actions to allow testing various
redirect configs.
In a future commit, this will allow testing redirects for the `stable`,
`rc` and `next` deployments via the Firebase config file (without
requiring changes in the Firebase console or DNS).

PR Close #43963

Refactor the `deploy-to-firebase` post-deploy actions by extracting
logic to separate helper functions. This makes it easier to create more
functions for testing various redirect configs (in a future commit).

PR Close #43963

feat(docs-infra): add more granular support for configuring Firebase redirects at deployment (#43963)

Previously, there was a `deploy-to-firebase` pre-deploy action for
configuring Firebase to redirect non-file requests to `angular.io`. This
is used for ensuring that `rc.angular.io` is correctly redirected to
`angular.io`, even when people have previously visited (and have a
ServiceWorker activated on) `rc.angular.io`.

This commit adds pre-deploy actions for configuring Firebase to redirect
a deployment to any of `angular.io`, `rc.angular.io` or
`next.angular.io` and also configure whether all requests or only
non-file requests will be redirected.
In a future commit, this will allow managing redirects for the `stable`,
`rc` and `next` deployments via the Firebase config file (without
requiring changes in the Firebase console or DNS).

PR Close #43963

Create functions to undo the changes made by any pre-deploy action.
In a future commit, this will allow deploying a build to multiple
projects/sites with different small tweaks for each.

PR Close #43963

Previously, the pre-computation of branch version info for the
`deploy-to-firebase` tests would always take place even when the tests
that used that info were skipped. This pre-computation involves network
access and may add a noticeable delay.

This commit refactors the tests to not do the pre-computation if the
corresponding tests are skipped. This allows for a faster iteration
when focusing on a different set of tests.

PR Close #43963

Move some functions that are used as post-deploy actions from
`deploy-to-firebase/index.mjs` to a separate file
(`deploy-to-firebase/post-deploy-actions.mjs`) to keep `index.mjs` small
and easier to maintain.

NOTE:
While not strictly necessary atm, `post-deploy-actions.mjs` uses the
same default export pattern for consistency with `utils.mjs`.

PR Close #43963