migrate aio to eslint as tslint has been deprecated, the migration is restricted to the aio app and
its e2e tests and does not include the other tools, for such reason both tslint and codelyzer have not
been removed (to be done in a next PR)
some minor tweaks needed to be applied to the code so that it would adhere to the new ESLinting behaviour
most TSLint rules have been substituted with their ESLint equivalent, with some exceptions:
* [whitespace] does not have an ESLint equivalent (suggested to be handled by prettier)
* [import-spacing] does not have an ESLint equivalent (suggested to be handled by prettier)
* [ban] replaced with [no-restricted-syntax] as there is no (official/included) ESLint equivalent
some rules have minor different behaviours compared to their TSLint counterparts:
* @typescript-eslint/naming-convention:
- typescript-eslint does not enforce uppercase for const only.
* @typescript-eslint/no-unused-expressions:
- The TSLint optional config "allow-new" is the default ESLint behavior and will no longer be ignored.
* arrow-body-style:
- ESLint will throw an error if the function body is multiline yet has a one-line return on it.
* eqeqeq:
- Option "smart" allows for comparing two literal values, evaluating the value of typeof and null comparisons.
* no-console:
- Custom console methods, if they exist, will no longer be allowed.
* no-invalid-this:
- Functions in methods will no longer be ignored.
* no-underscore-dangle:
- Leading and trailing underscores (_) on identifiers will now be ignored.
* prefer-arrow/prefer-arrow-functions:
- ESLint does not support allowing standalone function declarations.
- ESLint does not support allowing named functions defined with the function keyword.
* space-before-function-paren:
- Option "constructor" is not supported by ESLint.
- Option "method" is not supported by ESLint.
additional notes:
* the current typescript version used by the aio app is 4.3.5, which is not supported by typescript-eslint (the supported
versions are >=3.3.1 and <4.3.0). this causes a warning message to appear during linting, this issue should
likely/hopefully disappear in the future as typescript-eslint catches up
* The new "no-console" rule is not completely equivalent to what we had prior the migration, this is because TSLint's "no-console"
rule let you specify the methods you did not want to allow, whilst ESLint's "no-console" lets you specify the methods that you do
want to allow, so and in order not to have a very long list of methods in the ESLint rule it's been decided for the time being
to simply only allow the "log", "warn" and "error" methods
* 4 dependencies have been added as they have been considered necessary (see: https://github.com/angular/angular/pull/42820#discussion_r669978232)
extra:
* the migration has been performed by following: https://github.com/angular-eslint/angular-eslint#migrating-an-angular-cli-project-from-codelyzer-and-tslin
* more on typescript-eslint at: https://github.com/typescript-eslint/typescript-eslint
PR Close#42820
improve the @usageNotes message by adding the word "is"
(outcome: "Further information is available in...", compared to
"Further information available in...")
PR Close#42888
Previously, if there was more content than what would horizontally fit
in the main content area, it would overflow to the right and overlap
with the Table of Contents (ToC).
This was accidentally introduced in #42787.
This commit fixes it by ensuring that the main content area will not
overlap with ToC and the necessary space for the ToC will be reserved
using `margin` (instead of `padding`, which contributes to the element's
size).
Fixes#42867
PR Close#42884
Error-handling in AIO happens mainly in two places:
1. For errors happening inside the app we have a custom `ErrorHandler`
implementation, `ReportingErrorHandler`. `ReportingErrorHandler`
passes errors to the default `ErrorHandler` (for them to be logged to
the console) and also forwards them to `window.onerror()`.
2. Errors happening outside the app and errors forwarded by
`ReportingErrorHandler` are handled by `window.onerror()`, which in
turn reports them to Google analytics.
Previously, we were making some assumptions (which turned out to be
incorrect based on the info captured in Google analytics - see #28106):
- `ReportingErrorHandler` assumed that the errors passed to its
`handleError()` method would be either strings or `Error` instances.
_Apparently, other values (such as `null` or `undefined`) may also be
passed._
- `window.onerror()` assumed that if an `Error` instance was passed in,
it would always have a stacktrace (i.e. its `stack` property would be
defined).
_This is not necessarily true, although it is not clear (based on the
logs) whether reported errors of this type are caused by `Error`
instance with no stacktrace or by non-string error objects which are
incorrectly treated as `Error` instances.
This commit ensures that all types of error arguments can be handled
correctly, including `Error` instances with no stacktrace and other
types of objects or primitives.
NOTE:
PR #42881 is related as it fixes handling `null` and `undefined`
arguments in the default `ErrorHandler`.
Fixes#28106
PR Close#42883
This commit upgrades `lighthouse` to the latest version (8.1.0) to take
advantage of latest fixes/improvements and ensure the min scores are
still met with the latest audit changes.
PR Close#42846
Re-add reference to Trusted Types since the issue #41754 is resolved in 12.1.1.
This reverts commit 7254fbc2baa1455e3b24400597342843df3017f2.
PR Close#42796
The alert was placed in the middle of a set of steps, which
was causing some confusion. This has been moved to the
above the steps in the section and slightly reworded to
make it clearer.
Fixes#42752
PR Close#42764
Previously, the error message in the console would print `[object Object]`
and not the actual error message. With this change, the error message is
printed in the console.
PR Close#42773
Previously, on narrow pages where the sidenav was in `over` mode, the
sidenav's backdrop only covered the main docs content but not the
floating Table of Contents (ToC) on the right. This was inconsistent and
confusing to the user, because they could interact with the ToC and
scroll to different area of the main content while the sidenav and
backdrop were still covering the content.
This commit fixes it by ensuring the sidenav backdrop covers both the
main content and the floating ToC (when present).
Fixes#42778
PR Close#42787
This commit expands the info printed to the console to help diagnose
ServiceWorker issues to include the [internal debug info][1] retrieved
from `/ngsw/state`. This will provide more useful data, such as the
activated SW's version, state, clients, recent operations and any recent
errors.
NOTE:
This temporarily increases the payload size. Removing this code and
reclaiming the payload size is being tracked in #41117.
[1]: https://angular.io/guide/service-worker-devops#locating-and-analyzing-debugging-information
PR Close#42776
Fix a unit test warning due to Jasmine not realizing that
`httpMock.expectOne()` is an expectation.
[Example][1]:
> WARN: 'Spec 'DocumentService currentDocument should encode the request
> path to be case-insensitive' has no expectations.'
[1]: https://circleci.com/gh/angular/angular/1017640
PR Close#42776
Update `@angular/*` packages to latest 12.1.x versions (mainly to take
advantage of recent ServiceWorker improvements, such as #42607
and #42622).
PR Close#42776
make sure that the top-menu links don't get overlapped by
the search input, regardless on the browser's font-size and
the window's width
make also sure that the header's logo does not overlap the search
input on narrow windows, again regardless on the browser's font-size
PR Close#42753
Previously, the condition for showing the top-menu nav-menu in the
sidenav was the same as that for switching the sidenav mode from docked
(`mode: side`) to floating (`mode: over`). Therefore, the `isWide` input
of the corresponding `NavMenuComponent` could be hard-coded to `false`
(since the component would only be shown when the sidenav was in
floating mode).
In 61f6ed2fdfe58679cfada861624c759f1572a430, these two desicions were
decoupled, which would result in the top-menu nav-item being shown in
the sidenav while the sidenav is in docked mode (and thus the `isWide`
input should be set to `true`).
This commit fixes it by setting the `isWide` input based on the value of
the `dockSideNav` property, as happens for the rest of the nav-menus.
PR Close#42747
Previously, the `AppComponent#showTopMenu` property was taken into
account when determining the `MatSidenav#mode` value. However, this was
redundant, because in the only case in which the use of `showTopMenu`
would make a difference (i.e. when `dockSideNav` was true and
`isSideNavDoc` was false) the sidenav would be closed and the hamburger
menu button would not be visible (thus there would be no way to open it
manually).
This commit simplifies the condition for determining the sidenav mode by
removing `showTopMenu` from the expression.
PR Close#42747
This commit applies the necessary changes to make angular.io and (most)
docs examples compatible with both RxJS v6 and v7. It also adds new
steps to relevant CI jobs to test angular.io and docs examples against
RxJS v7 as well (to catch potential regressions).
NOTE:
Some of the docs examples are not compatible with RxJS v7 and are
therefore excluded from the tests. The SystemJS-based ngUpgrade
examples in particular are excluded, since they require a different
SystemJS configs to run against RxJS v6 and v7 and the extra complexity
of managing that is not worth it for the 4 affected examples.
PR Close#42660
This commit adds support for excluding certain docs examples from the
command used to run tests. This is useful to run extra tests on CI that
might not be compatible with all examples (for example, run tests with
different versions of a dependency).
In a subsequent commit, this will be used to run tests against RxJS v7
as a quick way to catch potential regressions.
PR Close#42660
When you click on `Understanding Angular > Components > Sharing data between
child and parent directives and components` in navigation sidebar, another
item gets selected: `Understanding Angular > Templates > Inputs and Outputs`
Both of them are linked to the same guide but the view cannot handle
situations when several entries point to the same guide.
This commit fixes that by removing the second entry.
Fixes#42652
PR Close#42654
Previously, the color of `<summary>` elements was hard-coded to `black`.
This did not work well on the dark theme, where the background color of
the page is also very dark.
This commit fixes it by removing the explicit color style, thus letting
`<summary>` elements inherit the color of their container.
Closes#42616
PR Close#42620
PR #41129 reorganized the SCSS files of the angular.io app moving most
of them in sub-directories. Due to incorrectly resolved merge conflicts
for PRs targeting the SCSS files around that time, we ended up with
duplicate style files for `<code>` elements:
- `styles/2-modules/_code.scss`
- `styles/2-modules/code/_code.scss` +
`styles/2-modules/code/_code-theme.scss`
This commit gets rid of the extra file (`styles/2-modules/_code.scss`)
and ports any changes from it to the correct files inside the `code/`
sub-directory.
PR Close#42620
In #41788, the `disambiguateDocsPathsProcessor` was introduced to fix
an issue with case-insensitively equal paths. This processor may alter
the output paths of some docs. Due to its nature, the
`disambiguateDocPathsProcessor` must be the last processor in the
pipeline that updates a doc's output path. However, the
`updateGlobalApiPathProcess` (which also alters the output paths of some
docs) was not configured to run before `disambiguateDocPathsProcessor`.
As a result, the changes made by `disambiguateDocPathsProcessor` were
overridden by `updateGlobalApiPathProcess`, resulting in the app's
failing to load such global API docs pages. An example of such an API
page is: https://angular.io/api/core/global/ngApplyChanges
This commit fixes it by ensuring that the `updateGlobalApiPathProcess`
is explicitly run before the `disambiguateDocPathsProcessor`, so that
the former does not override the changes made by the latter.
PR Close#42648
This commit includes the ServiceWorker version in the debug info shown
at `/ngsw/state` to make it easier to know what version of the
ServiceWorker script is controlling the page.
PR Close#42622
dario-piotrowicz
George Kalpakas
David Shevitz
Renovate Bot
Krzysztof Kotowicz
Alan Agius
Pete Bacon Darwin
Bastian
Ryan Andersen
Theoklitos Bampouris
mgechev
pavlenko
George Looshch
Lars Gyrup Brink Nielsen
codebriefcase
marvinbeckert
Dale Harris
