Since angular 11 extra package.json isn't generated and with version 12 strict mode is opt out bases.
Updated document to reflect the state
Closes#40841.
PR Close#41923
[`watchr` v4.0.0][1] changes the way watched directories are
scanned/watched, thus causing a great increase in the consumed CPU and
RAM. This affects the performance of the `docs-watch` and transitively
`serve-and-sync` npm scripts.
(For reference, on my local machine it goes from 0% CPU and 275MB RAM
with v3.0.1 to 50% CPU and 10GB RAM with v4+.)
This commit pins `watchr` to version 3.0.1 (which is the latest version
that does not cause performance issues) and disabled automatic updates
via Renovate.
[1]: https://github.com/bevry/watchr/releases/tag/v4.0.0
PR Close#41903
Previously example for handling client-side errors in networking didn't work when there was no Internet connection.
Caught error is ProgressEvent in such case, not ErrorEvent and error.error.message is undefined.
PR Close#36608
Follow-up to #41826
The CLI now no longer installs `ts-node` since Protractor has been removed.
See https://github.com/angular/angular-cli/pull/20601 for the relevant PR in angular-cli.
This change has been released in the CLI v12.0.0-rc.1
PR Close#41873
* `SelectivePreloadingStrategyService` is already provided in the root
module, so it should not be added to `AppRoutingModule` providers
array
PR Close#41859
With this change we add the `assert` polyfill which is required because `timezone-mock` is a Node.JS library which is being used in Browser.
PR Close#41764
In #41788, logic was added to disambiguate case-insensitively equal docs
paths/URLs. This process includes appending a `-\d+` suffix to some
paths/URLs (for example, `/.../inject-1`). Unfortunately, some of the
Firebase redirects configured in `firebase.json` would match these URLs
and redirect them to non-existing paths.
Example failures: [stable][1], [next][2]
NOTE:
This was not picked up in the regular CI tests run for PRs, because the
local devserver and the preview server used to test PRs do not support
Firebase-like redirects.
This commit fixes this by ensuring these disambiguated paths/URLs are
not matched by the redirect rules by checking whether the part of the
suffix after the `-` contains any numeric digits. While this check is
not ideal, it should be good enough for our purpose, since the legacy
URLs that we do want to redirect contain suffixes such as `-class`,
`-function` and thus no numeric digits.
[1]: https://circleci.com/gh/angular/angular/974345
[2]: https://circleci.com/gh/angular/angular/974346
PR Close#41842
In ##41788, the `disambiguateDocsPathsProcessor` was introduced to fix
an issue with case-insensitively equal paths. This processor may alter
the paths of some docs and thus their final URL in the app.
Previously, both the `disambiguateDocPathsProcessor` and the
`createSitemap` processor (which relies on the docs' computed paths to
generate the sitemap file) were configured to run before the
"rendering-docs" phase. However, this resulted in the
`disambiguateDocPathsProcessor`'s running after `createSitemap`, which
meant that the sitemap did not include the updated doc paths.
This commit fixes it by ensuring that the
`disambiguateDocPathsProcessor` is explicitly run before the
`createSitemap` processor, so that the latter will be able to take into
account any changes made by the former.
PR Close#41842
This commit includes the URL under test in the test description in
`testFirebaseRedirection.spec.ts` to make it easier to identify the
affected URL when a test fails.
It also avoids unnecessarily creating multiple `FirebaseRedirector`
instances by sharing instances between tests.
PR Close#41842
This commit updates the utilities in `firebase-test-utils/` to also
support testing Firebase redirects that are configured using regular
expressions (via the `regex` property).
See the [Firebase docs][1] for more details.
[1]: https://firebase.google.com/docs/hosting/full-config#redirects
PR Close#41842
Currently, the utilities for testing Firebase redirects assume that the
redirects are configured using the glob-based `source` property.
However, Firebase also supports configuring redirects using regular
expressions (via the `regex` property).
See the [Firebase docs][1] for more details.
This commit refactors the utilities in `firebase-test-utils/` to make it
easy to add support for such regex-based redirect configurations.
[1]: https://firebase.google.com/docs/hosting/full-config#redirects
PR Close#41842
Previously, the tests in `create-example.spec.ts` made assertions using
some hard-coded absolute paths (something like `/foo/bar`). This caused
the tests to fail on Windows, where the absolute paths are prefixed with
the drive letter (something like `C:/foo/bar`).
This commit uses `path.resolve()` to ensure paths are converted to the
format used on the current OS.
PR Close#41842
This section states that "Importing a module with services means that you will have a new instance of that service". This is only true for lazy-loaded `NgModules`. For non-lazy-loaded modules, my understanding is that the providers arrays are flattened into the root injector meaning that importing a module with a service doesn't create a new instance of that service.
PR Close#41835
These docs were linking directly to docs that have ambiguous paths.
These changes ensure that these links are not affected by the
disambiguation processing of those docs.
PR Close#41788
When two documents have the same `outputPath`, only differing by
letter casing, there can be problems on case-insensitive file-systems:
Only one of each of the docs would end up being written.
Moreover, the Webpack 5 bundler will error if it comes across files
that have this kind of ambiguous paths.
This commit adds a new docType: `disambiguator`, which will display
a list of the docs that match an ambiguous path. Each of the ambiguous
docs is then given a unique path and outputPath to ensure there are no
collisions.
PR Close#41788
Previously, the `autoLinkCode` Dgeni post-processor would not apply the
custom filters when matching the whole contents of a `<code>` element.
This meant that custom filters would not be applied to single-word
`<code>` elements.
You can see occurrences of this issue in the following sections of the
"Reactive forms" guide:
- [Creating nested form groups][1]
(look for `street, city, state, and zip controls`)
- [Using the FormBuilder service to generate controls][2]
(look for `group method`)
This commit fixes this by also applying the custom filters when
processing the whole contents of a `<code>` element.
This commit also updates the `filterPipes` custom filter to allow
matching a pipe's name in a single-word `<code>` element (where there is
no preceeding `|` character).
[1]: https://v10.angular.io/guide/reactive-forms#creating-nested-form-groups
[2]: https://v10.angular.io/guide/reactive-forms#using-the-formbuilder-service-to-generate-controls
PR Close#41709
While generating the docs, when a `<code>` element is inspected for
auto-linking, the `autoLinkCode` Dgeni post-processor will break its
contents up into words and generate text nodes for those words that
should not be auto-linked.
Previously, our text node visitor would visit these generated text nodes
and try to auto-link them too. As a result, it would unnecessarily
process nodes that had already been checked (and could potentially
generate links that would otherwise be ignored).
You can see an occurrence of this issue in the
[Create the product list][1] section of the
"Getting started with Angular" tutorial (look for `<a>`).
This commit fixes this by ensuring the visitor will skip the current
node and any nodes generated by `autoLinkCode`.
[1]: https://v11.angular.io/start#create-the-product-list
PR Close#41709
This commits makes the SystemJS-based docs examples more self-contained
by ensuring the necessary WebDrivers are fetched before running the e2e
tests.
This is a follow-up to #41689. (See there for more discussion.)
PR Close#41796