Upgrade local development environment for the angular repo to use node 14
dropping node 10 from supported for development within the angular repo.
PR Close#41544
Previously, the `angular-in-memory-web-api` package was built in
`dist/packages-dist/misc/angular-in-memory-web-api/`. This was different
from other Angular packages, which were placed directly in
`dist/packages-dist/`. This caused the `create-package-archives.sh`
script to create an invalid `misc.tgz` archive (i.e. treating the
`misc/` subdirectory as a package).
See, for example, the artifacts [here][1].
This commit changes the build scripts to have the
`angular-in-memory-web-api` package built in
`dist/angular-in-memory-web-api-dist/`, similar to how the `zone.js`
package is handled. It also updates the CircleCI config to correctly
publish the `angular-in-memory-web-api` package to CI build artifacts.
[1]: https://circleci.com/gh/angular/angular/951491
PR Close#41429
This commit updates the recommended `Dockerfile` for VSCode remote
development to take into account recent changes in our dev workflow
(updated Node.js version, vendored yarn, modified CircleCI config).
It also adds a note in the CircleCI config to keep the recommended
`Dockerfile` up-to-date with the Node.js version used on CI.
PR Close#41396
Removes BES configuration from CI bazel configuration as it is increasingly seeing timeouts
causing failures, but the uploaded results go largely unlooked at.
PR Close#40809
Previously, due to a bug in `rebase-pr.js`, PRs for branches containing
a slash (/) in their name would fail to be rebased
([example failure][1]).
This commit ensures that such branch names are handled correctly.
[1]: https://circleci.com/gh/angular/angular/884503
PR Close#40184
As part of the `setup` CI job (which is a prerequisite for all other CI
jobs), we rebase the current code on master to make sure the PR changes
are compatible with the latest code from master, even if the PR has not
been rebased recently.
When it is not possible to automatically rebase (i.e. when there are
conflicts that need to be resolved manually), the job and subsequently
the entire workflow should fail.
This behavior has been accidentally broken in #39592, so that the job
would succeed even if the rebase operation failed.
This commit fixes it by ensuring the `exec()` helper used in
`rebase-pr.js` will throw an error if the underlying command execution
fails. Previously, the function would always return stdout output as a
string and attach a `code` property indicating the exit code of the
command.
Since the exit code isn't necessary in the `rebase-pr.js` script, this
commit simplifies the `exec()` helper by making it return the stdout
output as a plain string (without extra properties) and re-throw any
errors (unless the `ignoreError` argument is set to `true`).
(Initially reported [here][1] by @JoostK.)
[1]: https://angular-team.slack.com/archives/C042EU9T5/p1608070403128900
PR Close#40161
In #32497, an option was introduced to retry failed docs examples tests
a second time. This was done to work around some then recently
introduced flakiness. After inspecting ~50 recent CI docs examples jobs,
all tests passed on the first try.
This commit gets rid of the retry attempt. This will avoid covering up
any new flakiness introduces in the future.
PR Close#39905
Migrate the rebase-pr script used on CI out of tools and into the circleci
directory. Additionally removes its support for running in the local
repository as this is now better handled by `ng-dev pr rebase <pr-number>`.
PR Close#39592
Update the cache keys used on CircleCI to bust the cache used in attempt
to address issue with tests on aio that are not reproducable locally.
Note: Going back to v1 as the cache version as caches are only held
for 15 days so we can safely return back to `v1` as the prefix
PR Close#39461
Add back the zone.js externs file test for google closure compiler.
The test compiles a test program with and without `zone_externs`.
1. With `zone_externs`, the code should keep the APIs defined in the `zone_externs`.
2. Without `zone_externs`, the code will not keep these APIs.
PR Close#39108
Zone.js 0.11.0 release an empty bundle, and now the npm_package tests all target
bazel rule `npm_package`, but not `npm_package.pack`, and these two rules may
generate different results, for example, Zone.js 0.11.0's issue is `package.json`
define files array which make the bundle only include the files in the files array.
So this PR install the zone.js package from the archive generated from `npm_package.pack` rule.
PR Close#38649
Because the compiler-cli tests modify node_modules, this can cause
failures on windows CI specifically as node_modules are symlinked
to rather than copied. By running the test and build actions in
separate commands, all of the tests are built to be executed before
and tests are executed and modify the node_modules content.
PR Close#39289
Rather than setting up windows by relying on attaching the saved workspace
failes from the previous step, instead checkout and install the yarn items
within the windows steps. Additionally, since the bazel remote cache is
used and relied on, saving the cached results of the bazel runs to be resumed
on subsequent runs does not provide enough value to make it worth the time
consumed.
PR Close#39139
Previously windows CI jobs were only run on upstream branches, with the addition
of larger Windows executors as well as the improvement of setup speed in the
windows environment setup script allows for the windows tests to pass in a
reasonable timeframe.
PR Close#39139
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.
Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0
Features of note for angular/angular:
* stdout/stderr/exit code capture; this could be potentially be useful
* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
heavy weight
Breaking changes of note for angular/angular:
* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
(which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`
* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.
* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
`@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
`@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
internals for ng_module.
* runfiles.resolve will now throw instead of returning undefined to match behavior of node require
Other changes in angular/angular:
* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.
NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.
* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.
PR Close#39182
Migrates to using larger resource classes for windows CI runs as well as updating
the bazel rcs for windows and linux to use all/more of the resources available in
the executors
PR Close#39124
Close#38851, support `jest` fakeTimers APIs' integration with `fakeAsync()`.
After enable this feature, calling `jest.useFakeTimers()` will make all test
run into `fakeAsync()` automatically.
```
beforeEach(() => {
jest.useFakeTimers('modern');
});
afterEach(() => {
jest.useRealTimers();
});
test('should run into fakeAsync() automatically', () => {
const fakeAsyncZoneSpec = Zone.current.get('FakeAsyncTestZoneSpec');
expect(fakeAsyncZoneSpec).toBeTruthy();
});
```
Also there are mappings between `jest` and `zone` APIs.
- `jest.runAllTicks()` will call `flushMicrotasks()`.
- `jest.runAllTimers()` will call `flush()`.
- `jest.advanceTimersByTime()` will call `tick()`
- `jest.runOnlyPendingTimers()` will call `flushOnlyPendingTimers()`
- `jest.advanceTimersToNextTimer()` will call `tickToNext()`
- `jest.clearAllTimers()` will call `removeAllTimers()`
- `jest.getTimerCount()` will call `getTimerCount()`
PR Close#39016
Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well
as breaking changes.
Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0
Features of note for angular/angular:
* stdout/stderr/exit code capture; this could be potentially be useful
* TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too
heavy weight
Breaking changes of note for angular/angular:
* loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl`
(which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl`
* with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is
no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing
a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm.
* @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that
require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from
`@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old
load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from
`@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library
internals for ng_module.
* runfiles.resolve will now throw instead of returning undefined to match behavior of node require
Other changes in angular/angular:
* integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true.
The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is
supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users
that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with
use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way
as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an
example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin:
https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect.
NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel
also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in
angular repo.
* JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions.
@josephperrott, this touches `packages/bazel/src/external.bzl` which will make the sync to g3 non-trivial.
PR Close#37727
This commit adds a new command to the `ng-dev` suite, which verifies that the NgBot YAML config is
correct. It also adds this command to the `lint` CircleCI job so that we execute this check while
running CI.
This should help prevent syntax errors similar to the one introduced in:
393ce5574b
PR Close#39071
Close#38584
In zone.js 0.11.1, the `types` field is missing in the `package.json`,
the reason is in zone.js 0.11.0, the `files` field is used to specify the
types, but it cause the npm package not contain any bundles issue, so zone.js
0.11.1 remove the `files` field, which cause the `type` definition gone.
This PR concat the `zone.js.d.ts`, `zone.configurations.api.ts`, `zone.api.extensions.ts`
types into a single `zone.d.ts` file.
PR Close#38585
Since the `defineProperty` not swallow error any longer, now the tests compile
source code in `commonjs` mode, and the code generated includes the code like this
```
Object.defineProperty(exports, "__esModule", {value: true});
```
And the `exports` is undefined in some browsers, but the error is swallowed before
this PR, and all tests run successfully, but it is not correct behavior. After this PR,
the code above failed. So we need to compile the source code in `umd` mode.
PR Close#37582
In the Angular Package Format, we always shipped UMD bundles and previously even ES5 module output.
With V10, we removed the ES5 module output but kept the UMD ES5 output.
For this, we were able to remove our second TypeScript transpilation. Instead we started only
building ES2015 output and then downleveled it to ES5 UMD for the NPM packages. This worked
as expected but unveiled an issue in the `@angular/core` reflection capabilities.
In JIT mode, Angular determines constructor parameters (for DI) using the `ReflectionCapabilities`. The
reflection capabilities basically read runtime metadata of classes to determine the DI parameters. Such
metadata can be either stored in static class properties like `ctorParameters` or within TypeScript's `design:params`.
If Angular comes across a class that does not have any parameter metadata, it tries to detect if the
given class is actually delegating to an inherited class. It does this naively in JIT by checking if the
stringified class (function in ES5) matches a certain pattern. e.g.
```js
function MatTable() {
var _this = _super.apply(this, arguments) || this;
```
These patterns are reluctant to changes of the class output. If a class is not recognized properly, the
DI parameters will be assumed empty and the class is **incorrectly** constructed without arguments.
This actually happened as part of v10 now. Since we downlevel ES2015 to ES5 (instead of previously
compiling sources directly to ES5), the class output changed slightly so that Angular no longer detects
it. e.g.
```js
var _this = _super.apply(this, __spread(arguments)) || this;
```
This happens because the ES2015 output will receive an auto-generated constructor if the class
defines class properties. This constructor is then already containing an explicit `super` call.
```js
export class MatTable extends CdkTable {
constructor() {
super(...arguments);
this.disabled = true;
}
}
```
If we then downlevel this file to ES5 with `--downlevelIteration`, TypeScript adjusts the `super` call so that
the spread operator is no longer used (not supported in ES5). The resulting super call is different to the
super call that would have been emitted if we would directly transpile to ES5. Ultimately, Angular no
longer detects such classes as having an delegate constructor -> and DI breaks.
We fix this by expanding the rather naive RegExp patterns used for the reflection capabilities
so that downleveled pass-through/delegate constructors are properly detected. There is a risk
of a false-positive as we cannot detect whether `__spread` is actually the TypeScript spread
helper, but given the reflection patterns already make lots of assumptions (e.g. that `super` is
actually the superclass, we should be fine making this assumption too. The false-positive would
not result in a broken app, but rather in unnecessary providers being injected (as a noop).
Fixes#38453
PR Close#38463
This commit updates the version of Angular CLI used in angular.io to
version 10.0.1. It also reverts some changes (namely commits 38dfbc775f
and eee2fd22e0) which were made due to an older bug that is fixed in
the latest version. See #37688 for more details.
Fixes#37699
PR Close#37898
As reported in #37699, the size of the main angular.io bundle sometimes
ends up bigger than expected on CI. This usually goes away after
rerunning the job a couple of times.
It is unclear what is causing this. In order to help debug the issue,
this commit stores the JS files that are checked as part of the aio
payload-size check as CI artifacts, where they can be retrieved from and
inspected.
PR Close#37703
Updates to the latest commit of the `angular/components` repository. We
need to do this because we removed the `esm5.bzl` output flavour aspect,
but an old version of the components repo relied on this file to exist.
This is no longer the case, and we can simply update the version of the
components repo we can test against.
PR Close#37623
Bazel invocations will upload to ResultStore to allow for us to have better viewing
of execution/build logs. This is only done on CI as the BES API requires credentials
from service accounts, rather than end user accounts.
PR Close#37560
Historically files to be formatted were added to a listing (via matchers)
to be included in formatting. Instead, this change begins efforts to
instead include all files in format enforcement, relying instead on an
opt out methodology.
PR Close#36940
Close#35157
In the current version of zone.js, zone.js uses it's own package format, and it is not following the rule
of Angualr package format(APF), so it is not easily to be consumed by Angular CLI or other bundle tools.
For example, zone.js npm package has two bundles,
1. zone.js/dist/zone.js, this is a `es5` bundle.
2. zone.js/dist/zone-evergreen.js, this is a `es2015` bundle.
And Angular CLI has to add some hard-coding code to handle this case, o5376a8b139/packages/schematics/angular/application/files/src/polyfills.ts.template (L55-L58)
This PR upgrade zone.js npm package format to follow APF rule, https://docs.google.com/document/d/1CZC2rcpxffTDfRDs6p1cfbmKNLA6x5O-NtkJglDaBVs/edit#heading=h.k0mh3o8u5hx
The updated points are:
1. in package.json, update all bundle related properties
```
"main": "./bundles/zone.umd.js",
"module": "./fesm2015/zone.js",
"es2015": "./fesm2015/zone.js",
"fesm2015": "./fesm2015/zone.js",
```
2. re-organize dist folder, for example for `zone.js` bundle, now we have
```
dist/
bundles/
zone.js // this is the es5 bundle
fesm2015/
zone.js // this is the es2015 bundle (in the old version is `zone-evergreen.js`)
```
3. have several sub-packages.
1. `zone-testing`, provide zone-testing bundles include zone.js and testing libraries
2. `zone-node`, provide zone.js implemention for NodeJS
3. `zone-mix`, provide zone.js patches for both Browser and NodeJS
All those sub-packages will have their own `package.json` and the bundle will reference `bundles(es5)` and `fesm2015(es2015)`.
4. keep backward compatibility, still keep the `zone.js/dist` folder, and all bundles will be redirected to `zone.js/bundles` or `zone.js/fesm2015` folders.
PR Close#36540
This change just fixes various typos and misspellings across several docs.
I've included also a fix for an issue surfaced via #37423.
Closes#37423
PR Close#37443
The info about the pw storage is out of date.
We should really just point the reader to a go link, something like go/angular/passwords and keep
the info about secrets there.
PR Close#37212
With 844208f463, we disabled the
components-repo-unit-tests job. The components repo landed the required
TS 3.9.x update, so we can re-enable the job again.
PR Close#37176
Updates the `components-repo-unit-tests` job to
d3a9ac67d2.
We need to update since we added a new diagnostic in ngtsc, and
the given commit in the components repo fixes failures caused by
the new diagnostic.
Note: This commit currently points to a PR as it's unlikely that
this fix lands soon, but we want to move forward. There is no
downside to doing that as the PR is based on top of the latest
components repo `master`.
PR Close#36921
Remove TypeScript 3.6 and 3.7 support from Angular along with tests that
ensure those TS versions work.
BREAKING CHANGE: typescript 3.6 and 3.7 are no longer supported, please
update to typescript 3.8
PR Close#36329
A caching mechanism was put in place to prevent repeated calls to
the Github API. As the CI setup no longer relies on calls to the
Github API, this caching is no longer necessary.
It was discovered that this caching was causing a contention issue
for saucelabs testing as the same tunnel was being reused for
multiple jobs simultaneously. With this caching mechanism removed
the jobs will once again run via separate tunnels.
PR Close#36936
Previously, in the `test_aio` CI job, we ran ngcc before building the
app with `yarn build`. This was supposed to have the benefit of taking
advantage of the parallel capabilities of standalone ngcc (vs implicitly
running it via `ng build`).
It turns out that the work done by the standalone ngcc was thrown away
before the `ng build`, resulting in `ng build` having to run ngcc all
over again. This happened because the `yarn build` script (run after the
standalone ngcc step) also runs `yarn install`, which essentially cleans
up `node_modules/`, thus discarding all the work already done by ngcc.
Here is an [example CI job][1], where this can be seen in action:
One can see the "Compiling <some-package> : es2015 as esm2015" logs in
the `yarn --cwd aio ngcc --properties es2015` step (as the standalone
ngcc processes the various entry-points) and then see the same logs in
the `yarn --cwd aio build --progress=false` step (as ngcc has to process
the entry-points all over again).
This commit removes the redundant standalone ngcc run and lets the CLI
handle ngcc via `ng build`. It is possible to instrument the build
process in a way that we can run the standalone ngcc after
`yarn install` and thus take advantage of the performance gains in
parallel mode, but the latest version of the CLI can already run ngcc in
parallel mode as a pre-build step, so this is unnecessary.
[1]: https://circleci.com/gh/angular/angular/658691
PR Close#36145
Migrates away from inline searching for files and running buildifier
directly, instead using ng-dev for formatting. Additionally, provides
a deprecation message for any usages of the previous commands.
PR Close#36842
Migrates away from gulp to ng-dev for running our formatter.
Additionally, provides a deprecation warning for any attempted
usage of the previous `gulp format:*` tasks.
PR Close#36726
Alan Agius
Joey Perrott
Pete Bacon Darwin
George Kalpakas
Alexey Elin
Marcono1234
JiaLiPassion
Greg Magolan
Andrew Kushnir
Paul Gschwendtner
JoostK
Igor Minar
Andrew Scott