The schematic code in `@angular/localize` is currently still emitted
as CommonJS, while the rest of `@angular/localize` is strict ESM (which
is also denoted through `type: module` in the package.json file).
The schematic code is currently imported as CJS from the CLI so it
is not a problem right now. Still, it is safer to ensure the code
for schematics is properly picked up as CJS through a local
`package.json` file resetting `type: module` to `type: commonjs`.
PR Close#44016
Sets up a minimal CLI project for testing that `ng add @angular/localize`
works as expected. Schematic sub-packages are prone to CJS/ESM issues
due the overall framework packages being denoted as strict ESM.
This may not be an issue in the concrete scenario of `@angular/localize`
right now, but it is still good to have an integration test similar to
the tests we have for `@angular/core` schematics.
PR Close#44016
This commit extends the logic of the `downgradeModule` function to support NgModule class as an argument. This is needed to simplify the API surface to avoid the need to resolve NgModule factory before invoking the `downgradeModule` method.
PR Close#43973
At present, the get() method provided by HttpContext will never return null. Sometimes we need to check whether an http token is included, so add the has() method to HttpContext.
PR Close#43887
Set up exporting the migration rules from the google3 directly from the internal
@angular/migrations package. This package is an internal only package to be
exposed for loading TSLint rules.
PR Close#43980
This commit changes the Stackblitz live examples to create "webcontainer" projects on Stackblitz.
This approach supports the new Angular v13 packaging formats but webcontainers are not supported on some browers. So this is a temporary solution.
PR Close#44041
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
This commit updates the docs examples to the latest prerelease versions
of Angular CLI, framework and CDK/Material.
It also updates the apps to more closely align with new apps CLI apps.
See also the [diff][1] between a basic v13.0.0-rc.0 CLI app and a
v13.0.0-rc.2 one.
[1]: cexbrayat/angular-cli-diff@13.0.0-rc.0...13.0.0-rc.2
PR Close#43583
Updates the size goldens for AIO to reflect the new measurements
after the v13 update to the latest release-candidates. i.e.
* rc.3 of Angular framework
* rc.2 of Angular CDK/Material
* rc.3 of Angular CLI.
Co-authored-by: George Kalpakas <kalpakas.g@gmail.com>
PR Close#43583
Updates AIO to the latest v13 release-candidate version of all
Angular-owned packages, such as Angular CDK and Angular Material.
Applies changes needed for the v13 CLI as performed by the CLI
through `ng update`:
7ff8c5350e/packages/schematics/angular/migrations/update-13.
Additionally, the web components polyfill has been removed as all browsers
supported by Angular seem to support custom elements v1 natively, according to:
* https://caniuse.com/custom-elementsv1
* https://www.webcomponents.org/ (scroll down to browser support)
Co-authored-by: George Kalpakas <kalpakas.g@gmail.com>
PR Close#43583
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
This reverts commit a268c4471f.
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
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
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
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
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
