When a UrlTree of root url was returned by a guard as a redirection, the
navigation was not processed. The issue came from the error handler which
incorrectly marked the router as already navigated.
Fixes#27845
PR Close#28271
Previously, `ng-packages-installer` would replace the version ranges for
all dependencies that were peer dependencies of an Angular package with
the version range used in the Angular package. This effectively meant
that the pinned version (from `yarn.lock`) for that dependency was
ignored (even if the pinned version satisfied the new version range).
This commit reduces non-determinism in CI jobs using the locally built
Angular packages by always using pinned versions of dependencies for
Angular package peer dependencies if possible.
For example, assuming the following versions for the RxJS dependency:
- **aio/package.json**: `rxjs: ^6.3.0`
- **aio/yarn.lock**: `rxjs@^6.3.0: 6.3.3`
- **@angular/core#peerDependencies**: `rxjs: ^6.0.0`
...the following versions would be used with `ng-packages-installer`:
- Before this commit:
- **aio/package.json**: `rxjs: ^6.0.0`
- **node_modules/rxjs/**: `6.4.0` (latest version satisfying `^6.0.0`)
- After this commit:
- **aio/package.json**: `rxjs: ^6.3.0`
- **node_modules/rxjs/**: `6.3.3` (because it satisfies `^6.0.0`)
PR Close#28510
`ng-packages-installer` can be used to replace Angular packages with
locally built ones (from `dist/packages-dist/`) along with their peer
dependencies.
Previously, in order to achieve this, `yarn install` was called with the
`--no-lockfile` option, which resulted in installing the latest versions
of all dependencies (including transitive ones) permitted by the
corresponding version ranges in `package.json` files. As a result, newly
released versions would be picked, resulting in unexpected,
non-deterministic breakages in CI.
This commit calls `yarn install` with the `--pure-lockfile` option
instead. As a result, only the Angular packages (for which the locally
built ones are used) and their peer dependencies are unpinned; the
pinned versions from `yarn.lock` are used for all other (direct and
transitive) dependencies.
While this does not eliminate non-determinism across builds, it
significantly reduces it.
PR Close#28510
Since b43f8bc7d, RxJS does not need to be patched any more in the
top-level `node_modules/`, so we don't need to special-case RxJS in
`ng-package-installer` and use `node_modules/rxjs/`.
PR Close#28510
The docs don't mention that the app will never be stable if a `setInterval` is running somewhere, and that it will prevent the servcie worker to be registered too.
PR Close#28102
Note that this allows Angular to depend on the entirety of the ES2015 API, not just our restricted subset.
This change is needed because our copy of the subset was out-of-date, and prevents us using ES2015 target in dev mode.
This is a subset of #27738
PR Close#28570
Previously, in order for the `aio_monitoring` failure notifications to
work, the steps up to `define_env_vars` should have succeeded. This
meant that any failures in earlier steps would not send notifications.
This commit fixes it by making the notification step independent of the
`define_env_vars` step.
PR Close#28555
In most cases, it doesn't make a difference, because the cache does
already exist and is not saved. In the few cases where the dependencies
change (and the cache needs to be updated), it makes more sense to save
the cache in the `build-npm-packages` job, because most jobs depend on
it and thus will be able to take advantage of the updated cache right
away.
This seems to be an oversight in b26ac1c22.
PR Close#28555
Currently our version of Yarn is installed through
the "circleci/node" docker image. This is problematic
because in order to be able to update Yarn, we always
need to update the docker image to a version that
comes with the desired Yarn version. Sometimes there
is no docker image with the desired latest Yarn version,
and therefore we cannot easily update the Yarn version.
Additionally updating the docker image also means that
we need to update our version of NodeJS, as well as the
version of `openssl` might have changed (meaning that
our encrypted credential files may not be decodable with
the new version of `openssl`)
PR Close#28546
Note that this fixes `compiler-cli` tests within `compiler-cli/test`,
but there seem to be remaining `ngcc` tests within `compiler-cli/src`
which aren't working on Windows. This is out-of-scope for this commit.
PR Close#28550
Currently the "ngtsc` testing helpers resolve the `fake_core` NPM
package using the `TEST_SRCDIR` variable. This is problematic on Windows
where Bazel runfiles are not symlinked into the runfiles directory.
In order to properly resolve the NPM Bazel tree artifact, we use the
`resolveTreeNpmArtifact` runfile helper that properly resolves the artifact
properly on all platforms.
PR Close#28550
In order to support running "compiler-cli" tests that use the "test_support.ts"
utilities on Windows with Bazel, we need to imporve the logic that resolves NPM
packages and symlinks them into a temporary directory.
A more Bazel idiomatic and windows compatible way of resolving Bazel runfiles
is to use the "RUNFILES_MANIFEST" if present. This ensures that the NPM
packages can be also symlinked on Windows, and tests can execute properly
on Windows. Read more about why this is needed here:
* https://github.com/bazelbuild/bazel/issues/3726#issue-257062364
PR Close#28550
Since we recently removed the `test.sh` script, and now run
all tests with Bazel, we can remove the unused logic that makes
compiler-cli tests pass in non-Bazel.
This cleans up the tests, and also makes it easier to write tests
without worrying about two ways of the Angular package output
(Bazel `ng_package` rules vs. old `build.sh` logic of building)
PR Close#28550
Since we recently removed the `test.sh` script, and now run all
tests with Bazel, we can remove the unused logic that makes language-service
tests pass in non-Bazel.
This cleans up the tests, and also makes it easier to write tests
without worrying about two ways of the Angular package output
(Bazel `ng_package` rules vs. old `build.sh` logic of building)
PR Close#28550
There is no debouncing when we store the scroll Position.
Currently, we have a message in the console after a while:
>Throttling history state changes to prevent the browser from hanging
see: https://bugs.chromium.org/p/chromium/issues/detail?id=786211 for more informations
PR Close#28368
Note that this allows Angular to depend on the entirety of the ES2015 API, not just our restricted subset.
This change is needed because our copy of the subset was out-of-date, and prevents us using ES2015 target in dev mode.
This is a subset of https://github.com/angular/angular/pull/27738
PR Close#28134
Occasionally, yarn's requests take more than 10 minutes to
complete/fail, by which time CircleCI jobs due to no output.
This commit works around the issue by periodically printing something to
stdout.
PR Close#28458
Previously all Bazel repositories were cached on CircleCI
because the `experimental_repository_cache` flag has been
specified and the given repository cache directory has been
included in the CircleCI cache storage.
The directory is currently still included in the CircleCI
cache storage, but the `--repository_cache` flag is no longer
specified, and the cache directory is basically empty all the
time. The flag seems to have been removed accidentally within
SHA c8b70ae8e4.
We should specifiy this flag on the CI again, so that Bazel
doesn't need to install the Bazel managed node modules
all the time. This would slow down analysis phase on CI; and also
makes us dependent on the Yarn/NPM registry which often times out
if we fetch a lot of dependencies.
Also in order to make sure that cached Bazel repositories are
also most of the time in sync with what's currently defined in
the workspace, we need to update the cache key.
PR Close#28515
Changes `gulp format` to format only changed lines by default
(`gulp format:changed`) and introduces a new task, `gulp format:all` to
format all source files. Since formatting only changed lines should be
the more common action, it makes more sense as the shorter default.
PR Close#28411
Currently whenever someone creates a pull request, the NPM dependencies
are downloaded and installed. This is problematic because we have a lot
NPM dependencies with potentially large files that would need to be
downloaded (e.g. the Bazel binaries).
The caches are currently not being restored because we added the
`{Branch}` variable to the CircleCI cache key. Since every PR has a different
branch name (e.g. `devversion/refs/heads/my-banch`), the cache keys would
never match an existing cache key, and the PR would start fresh by
downloading everything.
We can safely remove the `{Branch}` variable from the cache key because
it does not provide any value since the cached files are based on the state
of the `yarn.lock` file and not based on the current branch name. This reduces
our dependency on the slow and sometimes **flaky** Yarn registry. We should
try to depend as few as possible on external services (e.g. see how Saucelabs
flakiness can cause trouble for the caretaker; same applies to flaky Yarn installs)
PR Close#28480
