Prior refactorings caused unexpected g3 sync issues due to a patch that
changes the error documentation URL. This commit moves the base url into
a separate file to make this more apparent.
PR Close#43965
The `ErrorCode` enum in the `error_code.ts` file is governed by public
api guards but the other top-level exports from that file are exempt
from public api documentation and are therefore marked as `@internal`.
However, TypeScript is configured with the `stripInternal` compiler
option such that declarations with `@internal` markers are not emitted
into the `.d.ts` files, but this means that the reexports in the barrel
file end up referring to missing declarations.
The `stripInternal` option is considered internal and its documentation
states to use at your own risk (as per https://github.com/microsoft/TypeScript/issues/45307).
Having the option enabled is desirable for us as it works well for
hiding class fields that are marked `@internal`, which is an effective
way to hide members from the .d.ts file. As a workaround for the issue
with top-level symbols, the declarations with `@internal` markers are
moved to dedicated files for which no public api guard is setup,
therefore allowing their `@internal` markers to be dropped.
Fixes#43097
PR Close#43965
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
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
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
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
Move some functions that are used as pre-deploy actions from
`deploy-to-firebase/index.mjs` to a separate file
(`deploy-to-firebase/pre-deploy-actions.mjs`) to keep `index.mjs` small
and easier to maintain.
Also, rename the `removeServiceWorker()` function to
`disableServiceWorker()`, which is a little more accurate.
NOTE:
While not strictly necessary atm, `pre-deploy-actions.mjs` uses the same
default export pattern for consistency with `utils.mjs`.
PR Close#43963
Move some util functions from `deploy-to-firebase/index.mjs` to a
separate file (`deploy-to-firebase/utils.mjs`) to keep `index.mjs` small
and easier to maintain.
NOTE:
To make it easier to mock functions in tests, `utils.mjs` uses a default
export (instead of multiple named exports) and references local
functions through the default exported object.
PR Close#43963
The `deploy-to-firebase` script might have to deploy a single AIO build
to multiple projects/sites (potentially with small tweaks between each).
This commit adds a step to validate the computed deployments to ensure
they are compatible with each other (for example, that there is exactly
one primary deployment that builds the app and sets the theme/mode and
that all secondary deployments are compatible with the primary one).
PR Close#43963
This commit adds two new properties, `name` and `type`, to deployment
info data. This will make it easier to differentiate between deployment
targets (e.g. primary vs secondary) and will provide more informative
log messages.
In a subsequent commit, this new data can be used to validate the
computed deployments list.
PR Close#43963
This commit fixes a typo in an error message thrown in the
`deploy-to-firebase` script (`but it was but it was` --> `but it was`).
It also makes the error clearer when the request was not redirected.
Old error:
> Expected '<original-url>' to be redirected to '<expected-url>', but it
> was but it was redirected to 'undefined'.
New error:
> Expected '<original-url>' to be redirected to '<expected-url>', but it
> was not redirected.
PR Close#43963
This commit enables linting for the scripts in
`aio/scripts/deploy-to-firebase/`. It also makes the necessary changes
to the files to make linting pass.
PR Close#43963
This commit moves the `aio/scripts/deploy-to-firebase.js` script into a
new directory, `aio/scripts/deploy-to-firebase/`. This will make it
easier to break it up into multiple smaller files to better organize the
code (without polluting the `aio/scripts/` directory).
PR Close#43963
The `InjectFlags` argument was defined for both `getOrCreateInjectable()` and `Injector`, but was ignored in `NodeInjector`.
This PR adds support for getting parent token via `NodeInjector.get()`.
close#31776
PR Close#41592
Fix incorrect escape of special characters when rendering member heritage docs. Example: DefaultIterableDiffer docs incorrectly renders what this class implements - it does not fully display generic types of implemented interfaces.
PR Close#43956
Prior refactorings caused unexpected g3 sync issues due to a patch that
changes the error documentation URL. This commit moves the base url into
a separate file to make this more apparent.
PR Close#43527
The `ErrorCode` enum in the `error_code.ts` file is governed by public
api guards but the other top-level exports from that file are exempt
from public api documentation and are therefore marked as `@internal`.
However, TypeScript is configured with the `stripInternal` compiler
option such that declarations with `@internal` markers are not emitted
into the `.d.ts` files, but this means that the reexports in the barrel
file end up referring to missing declarations.
The `stripInternal` option is considered internal and its documentation
states to use at your own risk (as per https://github.com/microsoft/TypeScript/issues/45307).
Having the option enabled is desirable for us as it works well for
hiding class fields that are marked `@internal`, which is an effective
way to hide members from the .d.ts file. As a workaround for the issue
with top-level symbols, the declarations with `@internal` markers are
moved to dedicated files for which no public api guard is setup,
therefore allowing their `@internal` markers to be dropped.
Fixes#43097
PR Close#43527
The bootstrap tests that reused the same component (the `HelloRootCmp` one) were randomly failing due to the incomplete cleanup between tests. This commit ensures that the component bootstrap is fully cimpleted and there are no pending async actions before going to the next test.
PR Close#43933
In #43879, `UmdReflectionHost` was updated to deal with the new UMD
format used by Rollup, where the parenthesis is around the wrapper
function and not the wrapper function call.
For reference, this caused failures in the `ngcc-validation` repo
([example 1][1], [example 2][2]).
This commit updates `UmdRenderingFormatter` to also handle both UMD
formats. In order to validate the change, this commit also updates the
`UmdRenderingFormatter` tests to run against both UMD formats.
[1]: https://circleci.com/gh/angular/ngcc-validation/65916
[2]: https://circleci.com/gh/angular/ngcc-validation/65758
PR Close#43931
When an app version is detected as broken, the SW calls the
`Driver#versionFailed()` method. Previously, this method would in turn
call the `Driver#sync()` method, which writes some metadata about the
SW's state to the `ngsw:/:db:contol` cache. More specifically,
`Driver#sync()` persists info about all known app versions, which one is
the latest and also what version each client is assigned to.
However, no relevant info is changed inside `Driver#versionFailed()`, so
the call to `Driver#sync()` is redundant (since there are no changes
that need to be synced with the cache). This is a left-over from
before #43518, when `Driver#versionFailed()` used to update version
assignments and thus did require synchronization with the cache.
This commit removes the redundant `Driver#sync()` call to avoid an
unnecessary write to the cache.
PR Close#43680
Alex Rickabaugh