BREAKING CHANGE
In PR #19558, we fixed a bug in `TestBed.overrideProvider` where
eager providers were not being instantiated correctly. However,
it turned out that since this bug had been around for quite a bit,
many apps were relying on the broken behavior where the providers
would not be instantiated. To assist in the transition, the
`TestBed.deprecatedOverrideProvider` method was temporarily
introduced to mimic the old behavior so that apps would have a
longer time period to migrate their code.
2 years and 3 versions later, it is time to remove the temporary
method. This commit removes `TestBed.deprecatedOverrideProvider`
altogether. Any usages of `TestBed.deprecatedOverrideProvider`
should be replaced with `TestBed.overrideProvider`. This may mean
that providers that were not created before will now be instantiated,
which could mean that your tests need to provide more mocks or stubs
for the dependencies of the newly instantiated providers.
PR Close#30576
Context:
As part of the `test_docs_examples_ivy` job, we run 5 concurrent builds
on each VM (each for a different example/project). Additionally, all
example projects share the same `node_modules/` (via a symlink to
`aio/tools/examples/shared/node_modules/`), so all concurrent builds
operate on the same files.
Previously, we pre-ran ngcc with `--properties module` to process the
fesm5 bundles. Since we have switched to es2015 in 661a57d9e, we now
need the esm2015 bundles. As a result, the initial ngcc run is
redundant and ngcc runs again during each build (to process the fesm2015
bundles). Since there are 5 concurrent builds, we often end up with
multiple ngcc instances processing the same package and trying to write
to the same directories at the same time, causing a
`file already exists` error
This commit fixes it by pre-processing the esm2015 bundles, so there is
no need to re-run ngcc during each concurrent build.
Fixes#30577
PR Close#30593
docs: List only appears after the error is fixed
When the error happens, the list is not displayed too. Once the error is removed, the heroes list appears, so we can click and see the details.
PR Close#30529
The text for entry Style 04-10 of the style guide talks about
FilterTextService however, the example folder structure has the inversed
filename.
PR Close#30504
There is an encoding issue with using delta `Δ`, where the browser will attempt to detect the file encoding if the character set is not explicitly declared on a `<script/>` tag, and Chrome will find the `Δ` character and decide it is window-1252 encoding, which misinterprets the `Δ` character to be some other character that is not a valid JS identifier character
So back to the frog eyes we go.
```
__
/ɵɵ\
( -- ) - I am ineffable. I am forever.
_/ \_
/ \ / \
== == ==
```
PR Close#30546
after reading the context. there are some clues to infer the payload should be the `item`, not `item.name`.
1. EventEmitter<Item>.
2. the desc say that:
The component defines a deleteRequest property that returns an EventEmitter. When the user clicks delete, the component invokes the delete() method, telling the EventEmitter to emit an **Item** object.
PR Close#30429
The section on Data Binding makes a reference to "any experienced jQuery programmer" which is a bit too narrow since there are also programmers that write their front end in pure JavaScript.
PR Close#30386
Previously, the processor that excludes certain cli commands
(`filterHiddenCommand`) was being run after the `createSitemap`
processor, resulting in those commands to be present in `sitemap.xml`,
while the actual pages where missing. This also resulted in 404s, when
search engine crawlers tried to index the missing URLs.
This commit fixes it by ensuring that the `filterHiddenCommand`
processor is run before the `createSitemap` processor.
PR Close#30395
I updated the payload size limits as well. There still seem to be size regressions in the framework,
but at least the polyfills now uses the evergreen build of zones so we shaved off a few KB there.
PR Close#30183
Previously, the `aio_monitoring` job was testing both the stable
(https://angular.io/) and the @next (https://next.angular.io/) versions.
This commit splits the tests into two separate jobs (still run as part
of the same workflow). This speeds up the tests (since the two jobs can
now run in parallel) and makes it easier to isolate failures (e.g.
identify which branch is failing, disable one of the two, etc.).
(Credits to @petebacondarwin 😉)
PR Close#30110
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
The exact messages depend on the timing of several events and may vary
between runs. This occasionally causes flakes on CI.
This commit reduces the risk of flakes by loosen the conditions to only
check for what we actually care about.
Fixes#29544
PR Close#29757
This minimises the risk of unexpected failures due to breaking changes,
when building a new image (e.g. as a result of an unrelated config
change in Dockerfile).
PR Close#29976
Previously, the preview server docker image was based on Debian 8
(jessie). Recently, `jessie-updates` and `jessie-backborts` were removed
from the Debian mirrors ([more info][1]), thus breaking new builds of
the image.
Instead of updating `/etc/apt/sources.list` to remove the obsolete
sources, this commit upgrades to Debian 9 (stretch).
(The GCE VM running the preview server docker container was also
upgraded from Debian 8 to 9 this morning.)
---
Other changes:
- Removed dependency on `chkconfig`, which is not supported on Debian 9.
- Installing `nginx` from the regular repositories (instead of
`*-backports).
- Upgraded to `pm2` v3, which can handle hooking itself up to system
startup better (without `chkconfig` - see above).
- Updated tests to reflect the fact that `nginx` has dropped the reason
phrase in response status lines for HTTP/2 (in compliance with
[the spec][2]). (HTTP/1.1: `HTTP/1.1 200 OK` | HTTP/2: `HTTP/2 200`)
[1]: https://www.lucas-nussbaum.net/blog/?p=947
[2]: https://http2.github.io/http2-spec/#rfc.section.8.1.2.4
PR Close#29976
In #29926, the size of the build artifacts has increased due to turning
on differential loading (which generates an es2015/es5 pair for each JS
resource).
To avoid the preview server's rejecting the build artifacts (as in
[288181][1]), this commit increases the max allowed artifact size from
20MB to 25MB (current artifact size after #29926 is ~22MB).
[1]: https://circleci.com/gh/angular/angular/288181
PR Close#29976
In #29953, the wait period for SW on localhost was increased to avoid CI
flakes for the PWA score tests.
This commit expands the fix to non-localhost origins to avoid flakes in
the `aio_monitoring` job, when CircleCI VMs/network are slow.
(For reference, example failures: [289127], [289238])
[289127]: https://circleci.com/gh/angular/angular/289127
[289238]: https://circleci.com/gh/angular/angular/289238
PR Close#29988
In light of #29926, that will change the path of `tsconfig.app.json`,
this commit switches from a hard-coded `tsconfig.app.json` path to
looking it up in `angular.json` (to be more future-proof).
PR Close#29989
Previously, the `build-with-ivy` script could be used to build the `aio`
project with Ivy (once it had been prepared with `ivy-ngcc`, etc.) and
then restored the configuration (e.g. `tsconfig.json`) to non-ivy mode.
As a result, it was not useful for running other commands (e.g. unit/e2e
tests) in Ivy mode.
This commit renames the script to `switch-to-ivy` and employs a
different model (similar to `ng-packages-installer`), where the project
is setup to run in Ivy mode and then all subsequent commands are
executed in that mode (until restored).
Since this is currently only used on CI, there is no automatic way to
switch back to non-ivy mode (but it could be implemented in the future
if needed).
Finally, the script now modifies `src/tsconfig.app/json` instead of
`tsconfig.json` to ensure that the `angularCompilerOptions` are not
ignored/overwritten. This is also closer to what the cli generates
with the `--enable-ivy` option.
PR Close#29989
The server used for testing on localhost has less optimizations (e.g.
serves uncompressed files), so we need to wait longer the ServiceWorker
to be loaded and registered to allow Lighthouse to reliably detect it,
especially on slower environments (e.g. CI).
Related: https://github.com/GoogleChrome/lighthouse/issues/5527#issuecomment-483710849Fixes#29910
PR Close#29953
Brandon
Kara Erickson
George Kalpakas
Manohar Reddy Poreddy
janith
Fux, Etienne
Ben Lesh
jenniferfell
Kamil Myśliwiec
TwoDCube
Piotr Tomiak
Jimmy Kasprzak
Vincent Guo
Judy Bogart
Santosh Yadav
D3T0N8R
JiaLiPassion
dsychin
alimemonzx
Alan Agius
Mike Brocchi
William Koza
陈旭10045812
arjunyel
Richard Lea
Kapunahele Wong
Raja Rama Mohan Thavalam
Max Kramer
Brad Green
Igor Minar
Uday Vunnam
Suraj Poddar
Vani
Filipe Silva
Peter Johan Salomonsen
Igor Minar
Alex Eagle
Dustin M. Eastway
Andrew Kushnir
Trevor Karjanis
Kenny Schank
iliesaithamouda
Suguru Inatomi
Ahsan Ayaz