Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Workspaces support #5

Open
sirgalleto opened this issue Nov 10, 2020 · 1 comment
Open

[Question] Workspaces support #5

sirgalleto opened this issue Nov 10, 2020 · 1 comment

Comments

@sirgalleto
Copy link

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

  1. Gets the coverage-final.json file.
  2. Gets the updated files.
  3. 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

for example:

codeCoverage([
  {
    package: 'packages/package-a'
    ignoreCoveragePattern: ['.json', '.yml'],
    coverageFilesPath: 'packages/package-a/coverage/coverage-final.json'
  }, 
  {
    package: 'packages/package-b'
    ignoreCoveragePattern: ['.json', '.yml'],
    coverageFilesPath: 'packages/package-b/coverage/coverage-final.json'
  }
])

What do you think? I'm willing to take an action and code this implementation.

@Spoutnik97
Copy link
Owner

Spoutnik97 commented Nov 10, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants