Light house was reporting that 'Ensure text remains visible during webfont load' solution to this problem was adding &swap to the end of web fonts this leads to our first text showing before web-font download and improves the performance of site link to article: https://web.dev/font-display/\?utm_source\=lighthouse\&utm_medium\=lr
PR Close#35352
Previously, we needed to manually specify a ChromeDriver version to
download on CI that would be compatible with the browser version
provided by the docker image used to run the tests. This was kept in the
`CI_CHROMEDRIVER_VERSION_ARG` environment variable.
With recent commits, we use the browser provided by `puppeteer` and can
determine the correct ChromeDriver version programmatically. Therefore,
we no longer need the `CI_CHROMEDRIVER_VERSION_ARG` environment
variable.
NOTE:
There is still one place (the `bazel-schematics` integration project)
where a hard-coded ChromeDriver version is necessary. Since I am not
sure what is the best way to refactor the tests to not rely on a
hard-coded version, I left it as a TODO for a follow-up PR.
PR Close#35381
In #35049, integration and AIO tests were changed to use the browser
provided by `puppeteer` in tests. This commit switches the docs examples
tests to use the same setup.
IMPLEMENTATION NOTE:
The examples are used to create ZIP archives that docs users can
download to experiment with. Since we want the downloaded projects to
resemble an `@angular/cli` generated project, we do not want to affect
the project's Protractor configuration in order to use `puppeteer`.
To achieve this, a second Protractor configuration is created (which is
ignored when creating the ZIP archives) that extends the original one
and passes the approperiate arguments to use the browser provided by
`puppeteer`. This new configuration (`protractor-puppeteer.conf.js`) is
used when running the docs examples tests (on CI or locally during
development).
PR Close#35381
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
In https://github.com/angular/angular/pull/33058, we removed support
for the `ngForm` selector in the NgForm directive. We deleted most
of the deprecation notices in that PR, but we missed a paragraph
of documentation in the API docs for NgForm.
This commit removes the outdated paragraph that makes it seem like
the selector is still around and deprecated (as opposed to removed),
as it might confuse users.
PR Close#35435
Given:
```
<div class="s1" [class]="null" [ngClass]="exp">
```
Notice that `[class]` binding is not a `string`. As a result the existing logic would not concatenate `[class]` with `class="s1"`. The resulting falsy value would than be sent to `ngClass` which would promptly clear all styles on the `<div>`
The new logic correctly handles falsy values for `[class]` bindings.
Fix#35335
PR Close#35350
Root cause is that for perf reasons we cache `LFrame` so that we don't have to allocate it all the time. To be extra fast we clear the `LFrame` on `enterView()` rather that on `leaveView()`. The implication of this strategy is that the deepest `LFrame` will retain objects until the `LFrame` allocation depth matches the deepest object.
The fix is to simply clear the `LFrame` on `leaveView()` rather then on `enterView()`
Fix#35148
PR Close#35156
Includes new feature to honor .bazelignore in external repositories. rules_nodejs 1.3.0 now generates a .bazelignore for the @npm repository so that Bazel ignores the @npm//:node_modules folder.
PR Close#35430
Brings in feat: builtin: expose @npm//foo__all_files filegroup that includes all files in the npm package (https://github.com/bazelbuild/rules_nodejs/commit/8d77827) that is needed for npm_integration_test @npm//puppeteer pkg_tar on OSX (as the OSX Chrrome libs are extracted to paths that contain spaces)
PR Close#35430
- Fix minor typos in the Getting Started, Forms and AOT Compiler guide.
- Fix minor typo in the Tour of Heroes app.
- Fix coding styles in the Getting Started guide and the Tour of Heroes app
PR Close#35325
The update to Angular 9.0.0 appears to have lowered the main.js
file slightly, while the current master build of Angular appears
to have gone up slightly.
PR Close#35379
The previous range (^1.2.0) allowed the version 1.3.2 to be
installed which caused the ES2015 polyfills.js file to increase
in size unwantedly.
PR Close#35379
After the previous update to yarn.lock a problem surfaced
with the `mkdir-promise` package. The latest version of
dgeni-packages (0.28.3) fixes this problem.
PR Close#35379
This file had not been updated for some time and lots of
the dependencies have new versions.
This is actually necessary because (at least on OS/X) there
is a problem with `chokidar` and `fsevent` that is solved by
bumping the versions here.
PR Close#35379
Previously, the `deployment` section, was using the `firebase`
CLI to deploy the angular project into firebase. With the better
integration through the `fire` schematics, it is now easier to
deploy angular applications into firebase. This commit takes
care of this, by outlined the required steps for deployment.
Closes#35274
PR Close#35355
In the `loadRenderer` we make an assumption that the value will always be an `LView`, but if there's a directive on the same node which injects `ViewContainerRef` the `LView` will be wrapped in an `LContainer`. These changes add a call to unwrap the value before we try to read the value off of it.
Fixes#35342.
PR Close#35343
The message service was added in a section create message service but was impoted much before it removed those imports because they can be confusing
Fixes#35259
PR Close#35354
Previously, a section in the FAQ was not clear when discussing a
simple unit test. We also want to move away from question-based
sections. This commit clarified the confusing section and
changed all question-based sections.
Closes#35056
PR Close#35316
Verify that all files in the repo are covered by the pullapprove config
and that all rules in the pullapprove config match at least one file
in the repo.
PR Close#35060
Previously there was a regression in PullApprove which preventing draft mode
from being respected correctly for PullApprove processing. This regression
has been remedied and we should be able to once again respect draft mode for
PRs.
PR Close#35396
There is currently a bug in Chrome 80 that makes Array.reduce
not work according to spec. The functionality in forms that
retrieves controls from FormGroups and FormArrays (`form.get`)
relied on Array.reduce, so the Chrome bug broke forms for
many users.
This commit refactors our forms code to rely on Array.forEach
instead of Array.reduce to fix forms while we are waiting
for the Chrome fix to go live.
See https://bugs.chromium.org/p/chromium/issues/detail?id=1049982.
PR Close#35349
This means integration tests no longer need to depend on a $CI_CHROMEDRIVER_VERSION_ARG environment variable to specify which chromedriver version to download to match the locally installed chrome. This was bad DX and not having it specified was not reliable as webdriver-manager would not always download the chromedriver version to work with the locally installed chrome.
webdriver-manager update --gecko=false --standalone=false $CI_CHROMEDRIVER_VERSION_ARG is now replaced with node webdriver-manager-update.js in the root package.json, which checks which version of chrome puppeteer has come bundled with & downloads informs webdriver-manager to download the corresponding chrome driver version.
Integration tests now use "webdriver-manager": "file:../../node_modules/webdriver-manager" so they don't have to waste time calling webdriver-manager update in postinstall
"// resolutions": "Ensure a single version of webdriver-manager which comes from root node_modules that has already run webdriver-manager update",
"resolutions": {
"**/webdriver-manager": "file:../../node_modules/webdriver-manager"
}
This should speed up each integration postinstall by a few seconds.
Further, integration test package.json files link puppeteer via file:../../node_modules/puppeteer which is the ideal situation as the puppeteer post-install won't download chrome if it is already downloaded. In CI, since node_modules is cached it should not need to download Chrome either unless the node_modules cache is busted.
NB: each version of puppeteer comes bundles with a specific version of chrome. Root package.json & yarn.lock currently pull down puppeteer 2.1.0 which comes with chrome 80. See https://github.com/puppeteer/puppeteer#q-which-chromium-version-does-puppeteer-use for more info.
Only two references to CI_CHROMEDRIVER_VERSION_ARG left in integration tests at integration/bazel-schematics/test.sh which I'm not entirely sure how to get rid of it
Use a lightweight puppeteer=>chrome version mapping instead of launching chrome and calling browser.version()
Launching puppeteer headless chrome and calling browser.version() was a heavy-handed approach to determine the Chrome version. A small and easy to update mappings file is a better solution and it means that the `yarn install` step does not require chrome shared libs available on the system for its postinstall step
PR Close#35049
Under strict mode, the language service fails to typecheck nullable
symbols that have already been verified to be non-null.
This generates incorrect (false positive) and confusing diagnostics
for users.
To work around this issue in the short term, this commit changes the
diagnostic message from an error to a suggestion, and prompts users to
use the safe navigation operator (?) or non-null assertion operator (!).
For example, instead of
```typescript
{{ optional && optional.toString() }}
```
the following is cleaner:
```typescript
{{ optional?.toString() }}
{{ optional!.toString() }}
```
Note that with this change, users who legitimately make a typo in their
code will no longer see an error. I think this is acceptable, since
false positive is worse than false negative. However, if users follow
the suggestion, add ? or ! to their code, then the error will be surfaced.
This seems a reasonable trade-off.
References:
1. Safe navigation operator (?)
https://angular.io/guide/template-syntax#the-safe-navigation-operator----and-null-property-paths
2. Non-null assertion operator (!)
https://angular.io/guide/template-syntax#the-non-null-assertion-operator---
PR closes https://github.com/angular/angular/pull/35070
PR closes https://github.com/angular/vscode-ng-language-service/issues/589
PR Close#35200
Currently, would-be binding attributes that are missing binding names
are not parsed as bindings, and fall through as regular attributes. In
some cases, this can lead to a runtime error; trying to assign `#` as a
DOM attribute in an element like in `<div #></div>` fails because `#` is
not a valid attribute name.
Attributes composed of binding prefixes but not defining a binding
should be considered invalid, as this almost certainly indicates an
unintentional elision of a binding by the developer. This commit
introduces error reporting for attributes with a binding name prefix but
no actual binding name.
Closes https://github.com/angular/vscode-ng-language-service/issues/293.
PR Close#34595
Support for re-exports in UMD were added in e9fb5fdb8. This commit adds
some tests for re-exports (similar to the ones used for
`CommonJsReflectionHost`).
PR Close#35312
we should be documenting when an API is eligible for removal and not when it will be removed.
The actual removal depends on many factors, e.g. if we were able to automate the refactoring to
the recommended API in time or not.
PR Close#35263
ajitsinghkaler
George Kalpakas
Chives
Kara Erickson
Joey Perrott
Misko Hevery
Sonu Kapoor
Greg Magolan
Aristeidis Bampakos
Yoo In Keun
Pete Bacon Darwin
Igor Minar
crisbeto
Santosh Yadav
Alan Agius
JiaLiPassion
Keen Yee Liau
ayazhafiz
Judy Bogart
Francesco Leardini