An internal compiler option named `supportTestBed` is now available for use by the
Angular CLI. This option currently controls the extraction and emit of Angular class
metadata. This emitted information is only needed in AOT mode when using certain
TestBed APIs. However, AOT mode is currently not available for unit testing within
the Angular CLI. As a result, the metadata is not used within CLI generation applications
and in particular production applications. Without this option, the CLI needs to
manually perform a code transform to remove the metadata and also replicate TypeScript's
import eliding. This is can be a complicated operation and must be continually kept
up to date with any changes to both the Angular compiler and TypeScript. The introduction
of this new option alleviates these concerns.
PR Close#50604
Pawel and myself have investigated benchpress for quite some
time now, and I believe we have the most up-to-date understanding
in the team- so it would make sense to add us to the owners.
PR Close#50769
We have a lint rule configured that enforces that any abstract member
implementation uses an explicit `override` identifier. This ensures that
downstream classes will have errors if the parent abstract class
suddenly removes the abstract member.
The lint rule, living in the dev-infra repository, occasionally does
miss some places due to a temporary TS version mismatch that causes
syntax kind indices to be different. Looks like we are now matching
again and there is a new lint failure that got introduced recently. This
commit fixes that error.
PR Close#50772
Since we updated the devkit dependencies, we need to update
the browserslist DB versions in integration tests to avoid
browser mismatches causing errors like the following:
```
BrowserslistError: [BABEL] /tmp/ng-integration-test-91jP3g/test-sandbox/node_modules/zone.js/fesm2015/zone.js: Unknown version 114 of edge (While processing: "base$0$0")
```
PR Close#50772
This commit wraps the `assertNonZeroRenderedHeight` and `assertNoImageDistortion`
with `runOutsideAngular` to setup the `load` event listener outside of the Angular zone.
This was previously causing extra change detection cycles in development mode and
interfered debugging stuff.
PR Close#50723
`rev-parse` returns the original ref name in stdout, even if it wasn't
able to resolve the reference. This was preventing the upstream
resolution from never happening- causing `main` to be never resolved
to the actual SHA.
When we fetch e.g. `main`, the branch name will not be available
locally, and `rev-parse` will fail later. We can make the logic
more safe by just using `FETCH_HEAD` then.
PR Close#50767
If we try to resolve the benchmark compare ref (which may be just
`main`), we are just looking inside the PR branch- but that may
not include the `main` SHA. i.e. it's possible to run a comparison
where the PR is slightly behind of the `main` branch, or a comparison
commit from a different branch is used.
We fix this/ and simplify the logic by resolving the SHAs directly in
the TypeScript code, instead of relying on the rather brittle Bash.
Note that current solution still works, but we sometimes may not be able
to resolve to an actual SHA- causing issues as in 864bd72cb2
PR Close#50764
Currently the compare ref might be `main`. We will use that value
and put it into the GitHub results comment. This is non-ideal because
in the future `main` might be a different SHA and the results comment
would become invalid/confusing.
We fix this by resolving the actual SHA when the benchmark was
initiated.
The checkout action always assumes the main repository, but
the branch name/SHA of the pull request will be from a fork.
We fix this by using an updated action that exposes the branch
repo owner and name, so that we can check out the actual PR
branch/SHA.
PR Close#50758
This commit creates a GitHub action that runs benchmark comparisons
for a single target whenever a command comment is created by trusted
Angular organization members:
```
/benchmark-compare <compare-ref> <benchmark-target>
```
The benchmark will be run locally in Github actions, using the same
machine to minimize number deviation. The results are then printed
to the GitHub PR using a comment.
At current time, no actual "green/red" state is computed, but rather
the raw results are printed. In the future, since we have all the
metric data from the benchpress JSON logs, we could implement something
more easy to understand- but that's a follow-up/needs more discussion.
PR Close#50745
This commit creates a new script that solves the following use-cases:
- Running benchmarks. It's not trivial to figure out the benchmark
target names, and it's also easy to mess up the right Bazel flags.
- Performing comparisons. When e.g. working on a runtime senstive
change, it should be trivial to run benchmarks between the current
working stage, and a base revision (e.g. `main`).
The script takes care of both these use-cases and comes with a
prompt-based command line tool experience.
The script will also be used by a future GitHub action that can run
comparisons triggered via GitHub PR comment (by trusted team members).
PR Close#50745
This commit updates benchpress to include the text representation of
results in the JSON report. This is useful when results of multiple
tests are read from the Bazel testlogs and then printed together in
e.g. a GitHub comment, or at the end of a script (not in the middle
of the surroundings of the Bazel executions).
The text representation could have been built directly based on the
JSON raw metrics, but it would be unnecessary work and duplication
to get a similar output as with the console reporter- so we can
just include this information in the report.
PR Close#50745
A larger investigation on why this is flaky is needed. Currently the
test is flaky with around 77% sucess rate and negatively impacts team
productivity. Subjectively, as reported by team members this it's much
more flaky than a success rate of 77%.
PR Close#50718
Enables colors for Bazel in CircleCI. Bazel does not seem to
detect color support properly, but CircleCI does support such.
Colors make debugging a little easier with larger Bazel logs.
PR Close#50720
If a library is compiling with Angular v16.1.0, the library will break
for users that are still on Angular v16.0.x. This happens because the
`DirectiveDeclaration` or `ComponentDeclaration` types are not expecting
an extra field for `signals` metadata. This field was only added to the
generic types in `16.1.0`- so compilations fail with errors like this:
```
Error: node_modules/@angular/material/icon/index.d.ts:204:18 -
error TS2707: Generic type 'ɵɵComponentDeclaration' requires between 7 and 9 type arguments.
```
To fix this, we quickly roll back the code for inserting this metadata
field. That way, libraries remain compatible with all v16.x framework
versions.
We continue to include the `signals` metadata if `signals: true` is set.
This is not public API anyway right now- so cannot happen- but imagine
we expose some signal APIs in e.g. 16.2.x, then we'd need this metadata
and can reasonably expect signal-component library users to use a more
recent framework core version.
PR Close#50714
The component exposed by the fixture is not important thus marked as `unknown`.
Exposing the fixture of the `RouterTestingHarness` allows to use the methods & properties of that fixture and makes it compatible with testing libraries relying on `ComponentFixture`
Fixes#48855
PR Close#50280
If the compiler CLI is running through closure compiler, the trait
decorator handlers are converted from classes to functions as ES5
is picked as default output target for the bundled version.
The problem is that currently all trait handlers end up having the
same `name`. i.e. an empty string, and therefore adopting previous
traits from a previous build iteration result in the incorrect handler
being used for e.g. registrering, compiling etc- causing
ambiguous/confusing errors down the line in other parts.
We can look into changing the output target in the future, but even
then we are safer using an actual literal due to property renaming.
```$$closure$$NgModuleDecoratorHandler = function() {}`.
It is is questionable if we should just simply NOT run the compiler
through JSCompiler.
PR Close#50673
Andrew Kushnir