Which @angular/* package(s) are the source of the bug?
core
Is this a regression?
Yes
Description
While upgrading my application from v21 to v22, I came across a rather odd issue with the vitest engine. Before the upgrade, my testing suite would normally complete in ~60 seconds and generate a 100% statement covered report using the v8 coverage provider. After I upgraded my application to v22, while running the same application, same tests, same coverage provider, same source maps, minor changes (if any) to accommodate v22 upgrades, I observed two significant regressions:
- Test execution increased significantly from ~60 seconds to ~190+ seconds.
- v8 coverage incorrectly reports certain static import statements as uncovered, reducing code coverage from 100% to 95%.
Regarding angular/angular#2, the affected statements are primarily local application/library imports, but not only is the missing coverage inconsistent, the imported modules are actually executed and covered. In addition, the containing components are executed normally and their methods, declarations, everything else inside remains fully covered. I also attempted to use V8 ignore comments around the affected imports, but doing so caused the containing file to be reported with 0% coverage.
As you'll see in the environment below, these issues happen when I'm running @angular/build version 22.1.6. So I did a test, and downgraded my application to a working version of Angular 22 that uses @angular/build version 22.1.4. I ran the tests again. Everything was back to normal - 60s processing time, 100% full coverage of my code. In other words:
- @angular/build@22.1.6 - import statements reported uncovered, test suite takes ~190s.
- @angular/build@22.1.4 - import statements correctly reported as covered, test suite takes ~60s.
As it stands, I will have to remain on a version of Angular that uses @angular/build@22.1.4 until this issue has been resolved.
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
Please provide the environment you discovered this bug in (run ng version)
Angular: 22.1.3
Angular CLI: 22.1.6
@angular/build: 22.1.6 (problematic) / 22.1.4 (working)
Vitest: 4.1.7 or 4.1.11 (both tested)
@vitest/coverage-v8: 4.1.7 or 4.1.11 (both tested)
TypeScript: 6.0.3
sourceMap: true
Unit test builder: @angular/build:unit-test
Test command: ng test my-project --configuration --no-browser
Anything else?
No response
Which @angular/* package(s) are the source of the bug?
core
Is this a regression?
Yes
Description
While upgrading my application from v21 to v22, I came across a rather odd issue with the vitest engine. Before the upgrade, my testing suite would normally complete in ~60 seconds and generate a 100% statement covered report using the v8 coverage provider. After I upgraded my application to v22, while running the same application, same tests, same coverage provider, same source maps, minor changes (if any) to accommodate v22 upgrades, I observed two significant regressions:
Regarding angular/angular#2, the affected statements are primarily local application/library imports, but not only is the missing coverage inconsistent, the imported modules are actually executed and covered. In addition, the containing components are executed normally and their methods, declarations, everything else inside remains fully covered. I also attempted to use V8 ignore comments around the affected imports, but doing so caused the containing file to be reported with 0% coverage.
As you'll see in the environment below, these issues happen when I'm running @angular/build version 22.1.6. So I did a test, and downgraded my application to a working version of Angular 22 that uses @angular/build version 22.1.4. I ran the tests again. Everything was back to normal - 60s processing time, 100% full coverage of my code. In other words:
As it stands, I will have to remain on a version of Angular that uses @angular/build@22.1.4 until this issue has been resolved.
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
Please provide the environment you discovered this bug in (run
ng version)Anything else?
No response