You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I'm opening this PR because I see an opportunity to add support to workspaces/monorepos/multi-package repositories. You can find the npm RFC of the feature here
When you're working with workspaces, is common that each workspace has its own test suit, and maybe a custom configuration.
As far as I understand, the current plugin configuration
Gets the coverage-final.json file.
Gets the updated files.
Matches each file path with the info in the coverage-final.json
But in the case of a workspace, having multiple tests configuration and coverage-final.json or even packages with no tests, you end up with a non-reliable coverage report.
I think we can tweak this for workspaces adding multiple code coverage configurations with a package path to isolate the code-coverage analysis under that path
What I understand is that files modified in package-a are in the code-coverage analysis of the package-b whereas the package-b coverage-file.json does not include package-a files. So the coverage for these files are 0%. Do I understand well your problem ?
I think that test configurations should not influence the code-coverage, because this is the jest perimeter to pick the right configuration for each package. Whatever your test configuration, at the end you will have a coverage-file.json file that the plugin can analyze. Is it clear for you ?
To conclude,(tell me if I am right), you propose to ignore files outside each package for the code-coverage analysis, right?
Hi, I'm opening this PR because I see an opportunity to add support to workspaces/monorepos/multi-package repositories. You can find the npm RFC of the feature here
When you're working with workspaces, is common that each workspace has its own test suit, and maybe a custom configuration.
As far as I understand, the current plugin configuration
But in the case of a workspace, having multiple tests configuration and
coverage-final.json
or even packages with no tests, you end up with a non-reliable coverage report.I think we can tweak this for workspaces adding multiple code coverage configurations with a package path to isolate the code-coverage analysis under that path
for example:
What do you think? I'm willing to take an action and code this implementation.
The text was updated successfully, but these errors were encountered: