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
In Ivy, we support a new manual mode that allows for stricter control
over change detection in OnPush components. Specifically, in this mode,
events do not automatically mark OnPush views as dirty. Only changed
inputs and manual calls to `markDirty()` actually mark a view dirty.
However, this mode cannot be the default for OnPush components if we
want to be backwards compatible with View Engine. This commit re-adds
the legacy logic for OnPush components where events always mark views
dirty and makes it the default behavior.
Note: It is still TODO to add a public API for manual change detection.
PR Close#28474
Due to the fact that the test in 'ng_module_integration_spec.ts' relied on internal VE data structures (the '_def' field) to verify the state and the structure has changed in Ivy, this commit adds an Ivy version of the same test.
PR Close#28477
This commit fixes a bug in the Bazel builder in which the path to Bazel
executable is constructed using the project path. For non-default
project, the node_modules directory is actually one level above the
project path.
This PR fixes the bug by resolving node_modules with require.resolve().
It requires @bazel/bazel v0.22.1 because previous versions do not have
index.js or main field in package.json and would cause node module
resolution to fail.
This has been tested with both bazel and ibazel.
PR Close#28478
In 7cb8396, we improved the symbol test to remove suffixes from
the output, so "CIRCULAR$1" became "CIRCULAR". However, the logic
that checked for extra symbols depended on each symbol being unique.
If multiple symbols with the same name were added (e.g. pulled in
from separate files), they would be added to the map as "extras",
even if they were marked as expected in the golden file.
This commit updates the symbol checking logic to take multiple
symbols with the same name into account.
Closes#28406
PR Close#28459
Previously, attempting to destroy a view with listeners more than once
throws an error during event listener cleanup. This happens because
`cleanup` field on the `TView` has already been cleared out by the time
the second destruction runs.
The `destroyed` flag on LView was previously being set in the `destroyLView` function,
but this flag was never _checked_ anywhere in the codebase. This commit
moves _setting_ this flag to the `cleanupView` function, just before
destroy hooks are called. This is necessary because the destroy hooks
can contain arbitrary user code, such as (surprise!) attempting to
destroy the view (again). We also add a check to `destroyLView` to skip
already-destroyed views. This prevents the cleanup code path from running twice.
PR Close#28413
With the release of @angular/bazel v7.2.3, the npm install step right
after `ng new` installs this version. However there is a bug in the
builder which results in bazel executable not found.
This bug was not discovered before because the dependencies of the
project created by `ng new` are not pinned.
The fix is to pin the version of @angular/bazel to 7.2.2 which relies on
global installation of bazel.
PR Close#28460
This lets us run ngtsc under the tsc_wrapped custom compiler (Used in Bazel)
It also allows others to simply wire ngtsc into an existing typescript compilation binary
PR Close#28435