The docker-based AIO preview deploy setup is replaced with
significantly simpler setup using GitHub actions provided by
dev-infra (also something dev-infra can maintain better then).
The actions under the hood leverage Firebase preview channels.
PR Close#48345
Ocassionally the NodeJS version is not correct after NVM on Windows.
This adds some debug information that should help improve stability
here. A recent attempt to update the `$PATH` did not seem to help.
PR Close#48351
These steps builds AIO which is memory intensive. Running out of memory
may be the cause of some ci flakiness. Change the executor size to test
this theory.
For context: The CLI process is randomly getting `Killed`, likely by the
linux OOM killer. The Angular CLI builds happen on the host machine- no RBE.
Without the Bazel migration they were previously already at ~63% peak RAM.
With Bazel's overhead and e.g. remote caching, it seems to hit 100%
(can be seen in CircleCI machine insights). OOM killer may then choose the
highest consuming task. i.e. the Angular CLI and kill it.
Angular CLI build ram consumption is proportional to the size of the app. AIO is not small
https://app.circleci.com/pipelines/github/angular/angular/53992/workflows/ec47e3d8-2e7d-45b8-a802-7ec8ec4026c4/jobs/1265666/parallel-runs/0/steps/0-106https://angular-team.slack.com/archives/C02PARQNMC1/p1670067910332809i
PR Close#48342
We now set the Firebase deploy target for AIO preview deployment
via GitHub actions. It looks like configuring the deploy target
also requires authentication / or a project.
PR Close#48352
Checks out the Firebase project before setting the AIO preview targets.
Surprisingly Firebase requires a project when setting resource
identifiers for the targets. This is already done by the Firebase
deploy action from @FirebaseExtended, but we need to do it earlier.
PR Close#48347
For the deploy job we still need to use the Firebase CLI to configure
the proper hosting deploy targets. See:
011ef66a04.
We don't have node modules installed in this job, and it would
also be overkill to install them for just using firebase here.
Since the action uses `npx firebase-tools` down the line anyway,
we can use it without any speed downsides.
PR Close#48346
The AIO firebase project specifies `aio` as deploy target. This means
that we need to configure this target before being able to deploy AIO
previews.
We use the default project target as target since the preview Firebase
project does not use multi site targets. See:
https://firebase.google.com/docs/hosting/multisites
PR Close#48338
The `test_win` job is occasionally failing where a super old NodeJS
version is used even though we installed a proper one with `nvm`.
It's unclear how the CircleCI windows VMs differ here, it's coming
up rarely and is hard to reproduce when SSH-ing into VMs. Our best
guess is that the existing NodeJS version from the container/image is
super old and somehow takes precedence over the NVM-managed NodeJS
version. This could happen due to bad ordering in the `$PATH`
environment variable, or NVM not properly being wired up there.
We attempt to fix this by always setting `$PATH` to the NVM symlink
directory manually- with highest priority.
PR Close#48326
The `example-boilerplate` NodeJS binary always depends on all files from
the individual examples. This is not needed as for composition w/ the
boilerplate, only the target example content + boilerplate is needed
in the runfiles. This reduces the runfiles and therefore speeds up
boilerplate creation (which can happen for all examples concurrently).
PR Close#48329
AIO has two risk places where `node_modules` folders may exist and may
be accidentally picked up by Bazel- even though they are already added
as part of `.bazelignore` and made visible through `.gitignore`. It
doesn't hurt instructing Bazel to always ignore `node_modules` as part
of the `glob` instruction.
Co-authored-by: Joey Perrott <josephperrott@gmail.com>
PR Close#48329
When building AIO using `yarn build` the `--config=release` is added.
This was done as part of the Bazel migration to make sure the footer
shows a Git revision via Bazel stamping.
This does not provide enough benefits, compared to the downside of
reduced caching. Bazel will discard the analysis cache when the stamp
configuration changes.
This may happen easily when you work in framework where
`--config=release` is not used. Then when starting work in AIO: the
config changes and the cache is discarded. This may even mean that
existing framework package build artifacts may be discarded when an
AIO local build is started.
Co-authored-by: Joey Perrott <josephperrott@gmail.com>
PR Close#48329
These folders are no longer used in the source tree, and only exist
in the Bazel sandbox. We can rmeove them. Node modules are kept because
people may create them when editing the integration `package.json`
files.
PR Close#48329
It's very easy to have some random `node_modules/` folder floating
around in the repository. Especially coming from the old AIO
example boilerplate setup (which heavily relied on nested node modules).
These `node_modules/` folders can contain millions of files and might
be accidentally picked up by Bazel `glob`'s (if they are authored
in way that selects all nested files).
This could surface in `aio/tools/examples/shared` or individual content
examples, causing the Bazel analysis phase or runfile forest creation
to take forever given more than 1.5 files being dealt with.
Note that we keep the `examples/shared` node modules folder gitignored
as otherwise Renovate may have problems when updating the folder.
PR Close#48329
NgClass has non-negligable performance cost, especially if a
different object is provided as NgClass input (which was the case
for the NavItemComponent). The perfornace problem was noticed
in the scope of the INP score investigations while profiling the
https://angular.io/resources page. On this particular page replacing
NgClass usage with alternatives results in 20x (!) runtime perf
improvement. Such big improvement is possible since we avoid unneeded
CSS classes removal / adding in the DOM.
Part of #25518
PR Close#48312
Bazel otherwise may almost look as being stuck when it performs
many slow e2e tests. We should show what is running, even it results
in a little more output in the logs.
PR Close#48316
The `.bazelrc` workspace file attempted to imported the `.bazelrc.user`
file. This user file is set on CI to include the CI specific Bazel
settings.
Apparently this user rc import does not work, and fails silently given
the `try-import`. It fails because for AIO Bazel commands we change
the working directory using `yarn --cwd aio` and the `try-import`
is relative to the working directory..
PR Close#48316
The native UTF-8 encoder (`TextEncoder`) provides its output as a `Uint8Array`
which is a specialized `TypedArray` for storing byte values. To remove the need
to copy and transform this data multiple times, a `DataView` is used to allow
for low-level access to the data in a variety of bit-widths and endianness.
The `DataView` class is natively available and supported by all browsers and
Node.js versions support by the framework (https://caniuse.com/mdn-javascript_builtins_dataview).
PR Close#48256
Instead of relying on a custom implementation of a UTF-8 text encoder that needs to
be maintained by the Angular team, the i18n message digesting process now uses the
native `TextEncoder` class. This class is available for use in all browsers and Node.js
versions supported by the Angular framework (https://caniuse.com/textencoder). The
custom encoder is still used by the compiler's source map generator and cannot yet be
fully removed.
PR Close#48256
Because the language service uses the compiler, we try to produce as
much useful information as possible rather than throwing hard errors.
Hard errors cause the compiler to crash. While this can be acceptable
when compiling a program as part of a regular build, this is undesirable
for the language service.
PR Close#48314
This commit updates an internal `isStandalone` function and exposes it as a public API,
so that it can be used in applications code.
fixes#47919
PR Close#48114
This commit removes the unnecessary `assignExtraOptionsToRouter` helper
function. This helper is not necessary because the options can be
retrieved from DI and assigned during the construction on the Router.
PR Close#48215
The Router constructor and `setupRouter` factory mainly exist as a
legacy configuration. Since the Router's creation, the style in Angular
has evolved quite a bit. This commit eliminates and cleans up some
unnecessary comlicated code paths related to the router
constructor/factory.
Note that there are edits to the `setupTestingRouter` that could be seen
as breaking. However, it is not for several reasons:
1. The function is documented as a factory function. If used as
documented, the parameters should match what's available in DI
2. The function is totally unused by the Router itself and is not used
in g3 either. I believe it was made publicApi by an error when
updating documentation annotations long ago.
PR Close#48215
This commit removes several debug data structures from
the framework runtime. The data structures in question
were introduced in the framework in the past with the
idea of having debugging aid in the form of the human-redable
data structures. It turned out that in practice those
data structures were not used (most of the fwk developers
didn't even know about their existence!), yet we kept
paying the price of maintaining those duplicated (prod
and debug) version of the data structures.
PR Close#48281
