Extended diagnostics are enabled by default now and this flag doesn't do anything anymore but I missed it in a previous cleanup.

PR Close #46898

improve the error message for non-standalone components which are not
exported from their module, and that are also imported directly as if
they were standalone

this change simply adds the suggestion to the developer to import the
ngModule instead

resolves #46004

PR Close #46114

See associated pull request for more information.

PR Close #46853

* Adds a short note about how service workers report request timeouts
* Updated heading levels to present a clearer hierarchy and cleaner local TOC
* Removed documentation lint errors
* Moves the service worker service timeout paragraph to a more logical topic in service-worker-devops
* Removes line error from the more logical topic.
* address feedback from PR review comments

fixes #46445

PR Close #46882

The source map tests rely on asynchronous logic from the `source-map`
package. The tests itself are written using `fakeAsync` but this
unnecessarily complicates the interaction with the asynchronous
source-map helpers/package.

To fix this, we just make the tests use async/await as we don't intend
to test fakeAsync in this `describe` block..

PR Close #46888

The sourcemap test in the e2e playground is now using async/await code.
This results in errors now with the Bazel TS compilation because it
detects that `expect` is returning a promise and should be awaited.

This happens due to the jasminewd2 types. We should just use the actual
jasmine types and not rely on the deprecated selenium control flow,
using explicit async/await in the whole test. This also solves the issue
with the source-map types being async/await now.

PR Close #46888

The source-map package now requires the
`SourceMapConsumer`/`SourceMapGenerator` classes to be instantiated
asynchronously. This commit updates our tests to account for that.

PR Close #46888

The source-map package is no longer explicitly used in the
`compiler-cli` package and therefore can be removed from the ESBuild
bundling, denoting it as external. This should be a noop.

PR Close #46888

The source-map package is updated as part #46707, but the minor
version bump introduced breaking changes. This commit extracts the
update so that we can handle it separately accounting for the breaking
changes. Also removing the caret since this package apparently makes
breaking changes in minor segment bumps.

PR Close #46888

See associated pull request for more information.

PR Close #46885

See associated pull request for more information.

PR Close #46884

See associated pull request for more information.

PR Close #46883

The implementation of the `DefaultTitleStrategy` was modeled after the
existing strategy patterns in the Router. These patterns were developed
before the `providedIn` syntax for injectables. We can simplify the
model a lot by providing the default in the factory of the abstract
class.

Note that the other strategy patterns aren't touched in this PR due to
how long they've existed. Because they have been there for such a long
time, it's possible there will need to be some adjustments to code
if/when they are refactored to do the same.

PR Close #46876

style values get added to the `_globalTimelineStyles` map in order to keep
them so that they can be used across different timelines

`_globalTimelineStyles` was previously a plain object but has been
refactored to a map in #44482, as part of the update a check has been
changed from a ternary operation to an or (||), causing falsy values (as 0)
not to be added to the map anymore, apply the nullish coalescing operator (??)
instead to make sure only `undefined` and `null` are filtered out

also since this aspect was clearly not covered by tests, add a new test
to ensure that such regression doesn't happen in the future

resolves #46833

PR Close #46863

There are some ZoneJS tests that fork the zone from the `describe` block
for testing the zone patching. This does cause the Jasmine `done`
function later in `it` specs to be invoked in the sync-test zone from
the original `describe` block. The `done` implementation now has
changed with the Karma Jasmine update and breaks because it now causes
tasks to be scheduled.

It is conceptually incorrect/invalid to take the describe sync zone and
run test logic with that sync zone.

```
 An error was thrown in afterAll
  error properties: Object({ originalStack: 'Error: Cannot call jasmine.execute().forceTask from within a sync test (syncTestZone for jasmine.describe#FileReader).
      at new ZoneAwareError (packages/zone.js/test/browser_test_rollup.umd.js:98:37)
      at e.onScheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:158:196)
      at e.scheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:7529)
      at t.scheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:3539)
      at t.scheduleMicroTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:3791)
      at r.execute (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:166:4312)
      at queueRunnerFa ...
      at <Jasmine>
```

As mentioned in the previous commit that ensured that the Zone name is
included in errors raised by the `SyncTestZoneSpec`, we can now include
the Jasmine describe block descriptions in such errors.

Errors can often happen when users accidentally try to set up Angular
tests without an `it` block. Resulting in errors where it's not clear
at all which describe block (of potentially a large repository) is
involved:

```
 An error was thrown in afterAll
  error properties: Object({ originalStack: 'Error: Cannot call XX from within a sync test.
      at new ZoneAwareError (packages/zone.js/test/browser_test_rollup.umd.js:98:37)
      at e.onScheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:158:196)
      at e.scheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:7529)
      at t.scheduleTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:3539)
      at t.scheduleMicroTask (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:14:3791)
      at r.execute (packages/zone.js/bundles/zone-testing-bundle.umd.min.js:166:4372)
      at queueRunnerFa ...
      at <Jasmine>
```

We now include the describe block description in the error, so that it
is easier to figure out the location of the culprit code.

The sync-test zone is used in e.g. `describe` to raise an error when
there is asynchronous code scheduled in describe blocks. This commit
includes the zone name in such thrown errors to allow for us to include
the jasmine describe name in the error. This will be wired up in the
jasmine zonejs patches separately.

In the fake async test for `zone.js` there is some logic to test various
prefixes of the request animation frame functions. This logic does not
have any effect currently, except for generating the same test at
maximum three times.

This commit fixes the test to actually test what it meant to do
initially.

Karma jasmine updated the `jasmine-core` dependency. Jasmine is now more
strict when:

* The done callback is invoked multiple times
* The done callback is used, while a promise is also returned
* The done callback is treated as error when e.g. a number is returned
  as first argument. This was the case with `requestAnimationFrame`.

Currently tests written using `waitForAsync` would be prone to Jasmine
warnings or errors (depending on the version) for tests incorrectly
invoking asynchronous jasmine `done` callbacks multiple times.

This can happen because the async test zone logic schedules the
`done` callback to be called using `setTimeout`, but this could
be invoked multiple times, causing multiple `done` invocations to
be scheduled. Most of the issues have been resolved with #45025,
but it does not solve the case of multiple tasks finished and callbacks
being scheduled.

Technically, the current logic is built in way that _should_ result in
`_finishCallbackIfDone` and eventually the `done` callback to be invoked
at maximium once. This is unfortunately not the case in some rather
advanced/unexpected scenarios (like our AngularJS upgrade tests) where
the scenario is the following (and microtasks from before the actual
`waitForAsync` spec are still completing -- which is valid):

```
1. A test `beforeEach` schedules a microtask in the ProxyZone.
2. An actual empty `it` spec executes in the AsyncTestZone` (using e.g. `waitForAsync`).
3. The `onInvoke` invokes `_finishCallbackIfDone` because the spec runs synchronously.
4. We wait the scheduled timeout (see below) to account for unhandled promises.
5. The microtask from (1) finishes and `onHasTask` is invoked.

--> We register a second `_finishCallbackIfDone` even though we have scheduled a timeout.
--> we execute the `done` callback twice because the async zone spec state is "stable"
```

| datasource | package       | from  | to    |
| ---------- | ------------- | ----- | ----- |
| npm        | karma-jasmine | 4.0.2 | 5.1.0 |

Updating [angular#14.0.x](https://github.com/angular/angular/tree/14.0.x) from
[cli-builds#14.1.x](https://github.com/angular/cli-builds/tree/14.1.x).

##
Relevant changes in
[commit range](https://github.com/angular/cli-builds/compare/2cb508ffa...a6747c168):

**Modified**
- help/completion.json
- help/update.json

PR Close #46870

PR Close #46862

Applies the same logic that we have in the `control` function.

PR Close #46844

Revert "Revert "build: update cross-repo angular dependencies to 84dd092 (#46848)" (#46849)" (#46852)

This reverts commit b2a74469.

PR Close #46852

This reverts commit 510f4595.

PR Close #46849

See associated pull request for more information.

PR Close #46848

PR Close #46845

This adds two people to the docs-infra pullapprove group.

PR Close #46843

See associated pull request for more information.

PR Close #46834

See associated pull request for more information.

PR Close #46691

PR Close #46840

With the recent lock file maintenance, the `@types/angular` dependency
ended up being duplicated. This seems to happen because we locked our
type dependency, but other Angular deps like `angular-route` had a
looser dependency, resulting in e.g. `1.7` types and `1.8` types to be
loaded.

This ultimately ended up breaking TypeScript's auto-discovering
of types and broke some example compilations e.g.

```
app/app.animations.ts(3,3): error TS2339: Property 'animation' does not exist on type 'IModule'.
app/app.config.ts(5,45): error TS2694: Namespace 'angular' has no exported member 'route'.
app/phone-detail/phone-detail.component.ajs.ts(10,37): error TS2694: Namespace 'angular' has no exported member 'route'.
```

We fix this by loosening the type dependency ranges, updating all of
these. Also we update AngularJS itself to the final version.

PR Close #46840

The AIO payload size has been reduced with lock file maintenance which
resulted in updates of Angular framework and Angular devkit/CLI.

The same reduction is already visible in the `aio-local` job because
it was already using the latest FW packages (obviously -- given it being
from HEAD).

PR Close #46840

See associated pull request for more information.

PR Close #46840

Also remove lint errors.

Fix: #42781

PR Close #46832

refactor(core): improve an error message when `ENVIRONMENT_INITIALIZER` is not a multi provider (#46829)

Currently if the `ENVIRONMENT_INITIALIZER` token is not configured with `multi: true` flag, the code fails while trying to iterate over the value. This commit checks whether the `ENVIRONMENT_INITIALIZER` token value type is an array and throws a helpful error message.

PR Close #46829

Since Ivy is the default since v13, the Ivy guide (that used to live at
https://angular.io/guide/ivy) has been removed (see #43860). However,
there are certain error messages emitted by the CLI that still point to
it.

This commit address the problem by adding a redirect from
https://angular.io/guide/ivy to https://v12.angular.io/guide/ivy (which
is the last version that includes the guide).

Fixes #46717

PR Close #46820

The `Directive` and `Component` decorators support `inputs` and `outputs` fields which accept an array in the format of `"someInput"` or `"someInput: someAlias"`, however the parsing during JIT compilation was splitting on commas, not on colons, which resulted in incorrect parsing. E.g. `inputs: ["someInput: someAlias"]` was being parsed into `{"someInput: someAlias": "someInput: someAlias"}` instead of `{someInput: "someAlias"}`.

The feature was working by accident, because there's some logic further down in the compiler pipeline that was splitting the strings again.

PR Close #46813

PR Close #46812