fix(@angular-devkit/build-angular): ensure vitest code coverage handles virtual files correctly#31615
Conversation
clydin
force-pushed
the
unit-test/vitest-coverage-v4
branch
from
33c9979 to
d9767f9
Compare
clydin
added
the
action: review
…es virtual files correctly Vitest's default coverage provider checks for the physical existence of files to determine inclusion in the coverage report. This behavior excludes in-memory files generated by the build process from the final report. This change patches the `isIncluded` method of Vitest's `BaseCoverageProvider` to correctly account for these virtual files, ensuring they are included in the coverage analysis. Additionally, bundler-generated helper code chunks without any original source code can have empty sourcemaps. Vitest includes files with such sourcemaps in the coverage report, which is incorrect. This change adds a virtual source to these sourcemaps to prevent them from being included in the final coverage output.
clydin
force-pushed
the
unit-test/vitest-coverage-v4
branch
from
d9767f9 to
21a98b7
Compare
alan-agius4
added
action: merge
| // Temporary workaround to avoid the direct filesystem checks in the base provider that | ||
| // were introduced in v4. Also ensures that all built virtual files are available. | ||
| const builtVirtualFiles = this.buildResultFiles; | ||
| vitestCoverageModule.BaseCoverageProvider.prototype.isIncluded = function (filename) { |
There was a problem hiding this comment.
Patching private APIs instead of filing bug report on upstream is not recommended, ever.
I'm not sure why exactly Angular requires such hacky patch but it might as well be real bug on Vitest.
There was a problem hiding this comment.
Understood. It's temporary and we will be filing a bug and investigating further. This is intended to unblock downstream integration testing and allows us to test for potential breakage across a wider array of user projects in the interim. Additionally, in this case isIncluded is a public method on a public class that if it were changed upstream would cause breakage for all concrete providers so could not effectively be changed outside a major version.
There was a problem hiding this comment.
Btw, @clydin, is there any design doc or anything that highlights the pros and cons of separate build + virtual files vs. a vite transform plugin?
I am myself passionate about symmetry and would love to have everything built and bundled the same way but I feel that this is also breaking some of Vitest assumptions.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
4 participants
Vitest's default coverage provider checks for the physical existence of files to determine inclusion in the coverage report. This behavior excludes in-memory files generated by the build process from the final report. This change patches the
isIncludedmethod of Vitest'sBaseCoverageProviderto correctly account for these virtual files, ensuring they are included in the coverage analysis.Additionally, bundler-generated helper code chunks without any original source code can have empty sourcemaps. Vitest includes files with such sourcemaps in the coverage report, which is incorrect. This change adds a virtual source to these sourcemaps to prevent them from being included in the final coverage output.
Closes #31601