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

projects and collectCoverageFrom do not work together #9628

Closed
royra opened this issue Mar 2, 2020 · 11 comments
Closed

projects and collectCoverageFrom do not work together #9628

royra opened this issue Mar 2, 2020 · 11 comments

Comments

@royra
Copy link

royra commented Mar 2, 2020

🐛 Bug Report

We're using using Jest's projects feature to run tests in all packages of a monorepo concurrently. It's blazingly fast, and especially useful in CI ❤️ .

The problem is that some packages need to exclude a pattern (e.g, /index.js) from test coverage. Other packages need to include the same pattern in their test coverage.

Specifying collectCoverageFrom in each package's config works when running Jest at the specific package. When running at the repo root (using projects), the individual collectCoverageFrom props are ignored.

Specifying collectCoverageFrom at the root config does not work: The package path is not included in the tested path/glob, and so you cannot include package1/index.js while excluding package2/index.js.

To Reproduce

  • Have two packages with the same relative source filename, (e.g, index.js at the package root).

  • Try to include only one package's file in coverage, while excluding the other package's file.

Expected behavior

To keep things DRY, I would prefer if collectCoverageFrom at the root config would be inherited from the individual project's config.

Another option is specifying the project's path in collectCoverageFrom at the root:

{
  "collectCoverageFrom": [
    "packages/package1/index.js",
    "!packages/package2/index.js"
  ]
}

Link to repo

https://github.com/salto-io/jest_projects_coverage_issue

envinfo

 System:
    OS: macOS 10.15.3
  Binaries:
    Node: 12.14.1 - ~/.nvm/versions/node/v12.14.1/bin/node
    Yarn: 1.22.0 - ~/.nvm/versions/node/v12.14.1/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v12.14.1/bin/npm

Jest version: 25.1.0
(Also tried with 24.9)

royra pushed a commit to salto-io/jest that referenced this issue Mar 3, 2020
Moved the following config props from globalConfig to projectConfig:
collectCoverageFrom, collectCoverageOnlyFrom, coverageThreshold

You can now specify those properties per project.

As a side effect, they were removed from the whitelist of watch-able properties.
royra pushed a commit to salto-io/jest that referenced this issue Mar 4, 2020
Moved the following config props from globalConfig to projectConfig:
collectCoverageFrom, collectCoverageOnlyFrom, coverageThreshold

You can now specify those properties per project.

As a side effect, they were removed from the whitelist of watch-able properties.
royra pushed a commit to salto-io/jest that referenced this issue Mar 4, 2020
Moved the following config props from globalConfig to projectConfig:
collectCoverageFrom, collectCoverageOnlyFrom, coverageThreshold

You can now specify those properties per project.

As a side effect, they were removed from the whitelist of watch-able properties.
royra pushed a commit to salto-io/jest that referenced this issue Mar 4, 2020
Moved the following config props from globalConfig to projectConfig:
collectCoverageFrom, collectCoverageOnlyFrom, coverageThreshold

You can now specify those properties per project.

As a side effect, they were removed from the whitelist of watch-able properties.
@royra
Copy link
Author

royra commented Mar 4, 2020

Added PR #9633 which implements the DRY solution described above.

royra pushed a commit to salto-io/jest that referenced this issue Mar 25, 2020
Moved the following config props from globalConfig to projectConfig:
collectCoverageFrom, collectCoverageOnlyFrom, coverageThreshold

You can now specify those properties per project.

As a side effect, they were removed from the whitelist of watch-able properties.
royra pushed a commit to salto-io/jest that referenced this issue Mar 25, 2020
Moved the following config props from globalConfig to projectConfig:
collectCoverageFrom, collectCoverageOnlyFrom, coverageThreshold

You can now specify those properties per project.

As a side effect, they were removed from the whitelist of watch-able properties.
royra pushed a commit to salto-io/jest that referenced this issue Apr 12, 2020
Moved the following config props from globalConfig to projectConfig:
collectCoverageFrom, collectCoverageOnlyFrom, coverageThreshold

You can now specify those properties per project.

As a side effect, they were removed from the whitelist of watch-able properties.
@shahinghasemi
Copy link

The problem still exists, any solution?

rekmarks added a commit to MetaMask/metamask-extension that referenced this issue Sep 14, 2021
This PR adds build-time code exclusion by means of code fencing. For details, please see the README in `./development/build/transforms`. Note that linting of transformed files as a form of validation is added in a follow-up, #12075.

Hopefully exhaustive tests are added to ensure that the transform works according to its specification. Since these tests are Node-only, they required their own Jest config. The recommended way to work with multiple Jest configs is using the `projects` field in the Jest config, however [that feature breaks coverage collection](jestjs/jest#9628). That being the case, I had to set up two separate Jest configs. In order to get both test suites to run in parallel, Jest is now invoked via a script, `./test/run-jest.sh`.

By way of example, this build system feature allows us to add fences like this:

```javascript
this.store.updateStructure({
  ...,
  GasFeeController: this.gasFeeController,
  TokenListController: this.tokenListController,
  ///: BEGIN:ONLY_INCLUDE_IN(beta)
  PluginController: this.pluginController,
  ///: END:ONLY_INCLUDE_IN
});
```

Which at build time are transformed to the following if the build type is not `beta`:

```javascript
this.store.updateStructure({
  ...,
  GasFeeController: this.gasFeeController,
  TokenListController: this.tokenListController,
});
```

Co-authored-by: Mark Stacey <markjstacey@gmail.com>
@JCMais
Copy link

JCMais commented Oct 13, 2021

The solution in my case was to add the collectCoverageFrom to the root config (not inside projects)

@piranna
Copy link
Contributor

piranna commented Dec 22, 2021

I'm facing the same problem too.

@github-actions
Copy link

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Feb 17, 2023
@Yegorich555
Copy link

Ping

@github-actions github-actions bot removed the Stale label Feb 18, 2023
@thunder033
Copy link

We're hacking around this by dynamically including coverageThreshold values in our jest.config.ts:

const selectIndex = process.argv.indexOf('--selectProjects');
const endIndex = process.argv.findIndex((arg, i) => arg.startsWith('--') && i > selectIndex);
const projects = process.argv.slice(selectIndex + 1, endIndex > -1 ? endIndex : undefined);

const coverageThresholds: Record<string, CoverageThresholdValue> = {
  'apps/my-app': {
    lines: 25,
    statements: 25,
    branches: 17,
    functions: 20,
  },
};

const isSelectedProject = (path: string) =>
  projects.some((project) => path.split('/').includes(project));

export default {
   ...
   coverageThresholds: {
      global: {
        lines: 80,
        statements: 80,
        branches: 70,
        functions: 80,
      },
      ...Object.entries(coverageThresholds).reduce(
        (out, [path, value]) => ({ ...out, ...(isSelectedProject(path) ? { [path]: value } : {}) }),
        {},
      ),
   }
   ...
}

Copy link

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Mar 28, 2024
Copy link

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 27, 2024
@piranna
Copy link
Contributor

piranna commented Apr 27, 2024

No stale.

Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants