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
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
Previously, redirects had to be configured in both the Firebase config
(`firebase.json`) and the ServiceWorker config (`ngsw-config.json`).
This made it challenging to correctly configure redirects, since one had
to understand the different formats of the two configs, and was also
prone to getting out-of-sync configs.
This commit simplifies the process of adding redirects by removing the
need to update the ServiceWorker config (`ngsw-config.json`) and keep it
in sync with the Firebase config (`firebase.json`). Instead the
ServiceWorker `navigationUrls` are automatically generated from the list
of redirects in the Firebase config.
NOTE:
Currently, the automatic generation only supports the limited set of
patterns that are necessary to translate the existing redirects. It can
be made more sophisticated in the future, should the need arise.
PR Close#42452
The ServiceWorker `navigationUrls` globs defined in `ngsw-config.json`
are supposed to exclude any URLs that are redirected on the server (as
configured in `firebase.json`). However, the list of redirected
URLs/globs in `firebase.json` and `ngsw-config.json` have gotten out of
sync.
This commit updates the globs in `ngsw-config.json` to match the ones in
`firebase.json`.
This is in preparation of automatically generating the ServiceWorker
`navigationUrls` based on `firebase.json`.
PR Close#42452
Previously, only sub-paths, such as `api/http/foo`, were redirected to
`guide/deprecations#http`.
This commit ensures that also `api/http` itself (which used to point to
the `http` module's API page) is redirected as well.
PR Close#42452
This commit adds a test assertion to verify that all redirect rules
defined in `firebase.json` are tested, i.e. that each rule is applied to
at least one testcase from `URLS_TO_REDIRECT.txt`.
This will ensure that any redirect rules added in the future will be
tested.
PR Close#42452
Previously, the `destinations` test suite in
`testFirebaseRedirection.spec.ts` was nested under the
`with legacy URLs` test suite. However, the two suites are unrelated and
there is no reason to have them nested.
This commit moves the `destinations` test suite to be beside (instead of
inside) the `with legacy URLs` one.
PR Close#42452
This commit adds testcases in `URLS_TO_REDIRECT.txt` for all redirect
rules defined in `firebase.json`. This ensures that all rules are tested
and work as expected.
PR Close#42452
This reverts commit 61ad68a586135a4d7b2b920fda0cb4238c6422fe, since there
are no longer any disambiguated paths that need special handling.
PR Close#42414
To avoid having content files that have the same file path on case-insensitive
file-systems, we now encode the paths to remove uppercase characters.
PR Close#42414
Previously, due to a bug in Firebase hosting, requests to
`/index.html?<query>` would lead to an infinite redirect and eventually
a failure. This affected, for example, cache-busting requests from the
ServiceWorker, which look like: `/index.html?ngsw-cache-bust=...`
For more details see
https://github.com/angular/angular/issues/42518#issuecomment-858545483
This commit temporarily works around the bug by explicitly redirecting
`/index.html?<query>` to `/?<query>`.
Fixes#42518
PR Close#42547
Since #41625, `/guide/updating-to-version-10` is being redirected to
`https://v11.angular.io/guide/updating-to-version-11`. However,
`v11.angular.io` itself is being redirected to `angular.io`, while v11
is the latest stable version. As a result,
`/guide/updating-to-version-10` ends up being redirected to
`https://angular.io/guide/updating-to-version-11`. Currently, this
causes a CI failure in the `aio_monidoting` job ([example failure][1]).
This will change once v12 is released as the new stable version.
Alternatively, we could update the config and tests to expected
`/guide/updating-to-version-10` to be redirected to
`https://angular.io/guide/updating-to-version-11`, but that would end up
being redirected to `https://angular.io/guide/updating-to-version-12`
once v12 would be released, which is different behavior.
This commit provides a way to test for redirects when the destination
URL is itself redirected to a different URL. This allows us to use the
intended URL (for example, `https://v11.angular.io/...`), which will
continue to work as expected regardless of what is the latest stable
version without causing CI failures.
[1]: https://circleci.com/gh/angular/angular/983738
PR Close#42018
Previously, the `updating-to-version-*` URLs would redirect to the next
version update guide. More specifically:
- `/guide/updating-to-version-10` --> `https://v11.angular.io/guide/updating-to-version-11`
- `/guide/updating-to-version-11` --> `/guide/updating-to-version-12`
This seems confusing and inconsistent. Either all URLs should redirect
to the latest update guide (currently `/guide/updating-to-version-12`)
or each URL should redirect to the corresponding version.
This commit implements the second approach:
- `/guide/updating-to-version-10` --> `https://v10.angular.io/guide/updating-to-version-10`
- `/guide/updating-to-version-11` --> `https://v11.angular.io/guide/updating-to-version-11`
PR Close#42019
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
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
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
Previously, the `URLS_TO_REDIRECT.txt` file was expected to separate
URLs by a `\t` character. This could easily been mistaken for a regular
space and would often result in test errors when updating the file.
This commit updates the `URLS_TO_REDIRECT.txt` file and the
corresponding test helpers to use `-->` (potentially surrounded by
whitespace) as a separator for the URLs. This also gives a hint about
the "from" --> "to" relationship of the redirect URL pair.
PR Close#41680
Previously, the `URLS_TO_REDIRECT.txt` file was expected to not contain
any empty lines. This could easily result in test errors when updating
the file, since it is common for IDEs/editors to automatically ensure
there is an empty line at the end of a saved file
([example failure][1]).
This commit updates the test helpers to be able to cope with empty or
whitespace-only lines in `URLS_TO_REDIRECT.txt` by ignoring such lines.
[1]: https://circleci.com/gh/angular/angular/965534
PR Close#41680
Previously if there was a problem when building the tests, the error would
be swallowed as an unhandled promise rejection. Now these are caught and
the process is exited with a non-zero value to prevent any CI jobs from
passing incorrectly.
PR Close#41596
This commit tries to improve the search results by processing
the query and attempting progressively less restrictive searches
until a non-zero set of pages is matched.
The new procesing includes:
* stripping off quote marks, which were causing searches to fail
* first attempting to match pages where ALL the query terms exist
* second attempting to match pages where ANY of the query terms exist
* third attempting to match pages where the title contains partial word matches
The first query attempt approximates, quite well, the idea of searching
for multi-word phrases. This is given the technical nature of the terms
and the fairly small size of the corpus.
PR Close#41368
This commit updates `@angular/*` and `@angular/cli` (and related
packages) to version 11.0.0-rc.2. Apart from the automatic migrations,
this commit also tries to align `aio/` with new apps generated by the
latest CLI. (See [here][1] for a diff between a v10.1.3 and a
v11.0.0-rc.2 CLI app.)
[1]: https://github.com/cexbrayat/angular-cli-diff/compare/10.1.3...11.0.0-rc.2
PR Close#39600
The Displaying Data in Views topic is actually a small tutorial
that describes Angular features such as interpolation and
structural directives. These content is already covered in
our getting started tutorial and in Tour of Heroes.
This change adds redirects to the Template Syntax section
of the Getting Started tutorial and deletes displaying-data.md.
PR Close#38885
Update the Angular CLI and Angular framework packages to latest `@next`
versions. Also, update the app to look more closely to how a newly
generated app with the latest CLI would look like.
PR Close#36145
This is a follow-up to #35049 with a few minor fixes related to using
the browser provided by `puppeteer` to run tests. Included fixes:
- Make the `webdriver-manager-update.js` really portable. (Previously,
it needed to be run from the directory that contained the
`node_modules/` directory. Now, it can be executed from a subdirectory
and will correctly resolve dependencies.)
- Use the `puppeteer`-based setup in AIO unit and e2e tests to ensure
that the downloaded ChromeDriver version matches the browser version
used in tests.
- Use the `puppeteer`-based setup in the `aio_monitoring_stable` CI job
(as happens with `aio_monitoring_next`).
- Use the [recommended way][1] of getting the browser port when using
`puppeteer` with `lighthouse` and avoid hard-coding the remote
debugging port (to be able to handle multiple instances running
concurrently).
[1]: https://github.com/GoogleChrome/lighthouse/blame/51df179a0/docs/puppeteer.md#L49
PR Close#35381
This commit includes the following types of changes:
- Remove unused dependencies.
- Move dev dependencies from `devDependencies` to `dependencies` (and
vice versa for production dependencies).
- Update `@types/*`.
- Update dependencies to more closely match the dependencies installed
by the latest CLI for new apps.
Also, ensured that the latest version of `webdriver-manager` (v12.1.7)
was installed for `protractor`, which correctly installs a ChromeDriver
version that is compatible with the latest version of Chrome.
PR Close#32980
This commit also changes the config files and their layout to
(reasonably closely) match what the cli would generate for a new app.
Related Jira issue: [TOOL-815](https://angular-team.atlassian.net/browse/TOOL-815)
PR Close#29926
This ensures that the SW is cleaned up, even in cases where
synchronization is disabled (and thus the clean-up inside `goTo()`
happens without waiting for Angular).
PR Close#28290
For asynchronous callbacks, this can be done either by calling
`done.fail()` or by returning the promise directly (without requesting a
`done` callback). (Using the latter, because it is shorter.)
PR Close#28290
Occasionally, URLs take longer to load, which causes CI flakes.
In #27903, the timeout for external URLs was increased, but internal
URLs turned out to be affected as well.
PR Close#28103
dario-piotrowicz
George Kalpakas
Pete Bacon Darwin
mgechev
Kapunahele Wong
David Shevitz
Greg Magolan
jenniferfell
Vani
Paul Gschwendtner