How to exclude some files and folders from coverage report?

[MykytaLiashenko]

I am trying to exclude some JS files from coverage report.
I have already added this to package.json

"jest": {
    "testPathIgnorePatterns" : ["<rootDir>/node_modules/", "<rootDir>/path/to/dir/" ],
    "testResultsProcessor": "./node_modules/jest-junit-reporter"
  }

Unfortunately files from those dir still appear when I run CI=true npm test -- --coverage

[robcaldecott]

OK, I needed to ignore all *.stories.js files and you can do this by overriding the value for the Jest collectCoverageFrom option, which can be passed on the command-line via a custom npm test command. Note that collectCoverageFrom expects an array so to pass multiple values you specify the option multiple times.

For example:

npm test -- --coverage --collectCoverageFrom=src/**/*.js --collectCoverageFrom=!src/**/*.stories.js

Notice the exclamation point (can I still call it a pling or does that betray my age?) to exclude a pattern.

[MykytaLiashenko]

@robcaldecott
Unfortunately I have an error every time I try to pass param with exclamation point.
bash: !src/**/*.stories.js: event not found

[MykytaLiashenko]

Can I override the value for the Jest config option in another way?

[robcaldecott]

How about adding the command to an npm script in your package.json? Does that work with bash?

[MykytaLiashenko]

It works. Thanks.
Is this feature documented?Could I add it to Readme?

[amandapouget]

This is not a great solution because you have to type out the options in the CLI every time. I'd rather put my 'exclude xyz folders' into the package.json and forget about it. Can someone give an example, with react scripts, of how to modify this line so that your solution works?

    "test": "CI=true react-scripts test --env=jsdom",

[MykytaLiashenko]

@mandysimon88
Actually there are two solutions and the second fits to you.
"test" : "CI=true react-scripts test --env=jsdom --coverage --collectCoverageFrom=src/**/*js --collectCoverageFrom=!src/path/to/file"

[gaearon]

This is commonly requested & we should support this.

[MykytaLiashenko]

We could just add whole list of possible variants to documentation.

[gaearon]

@NikitaLiashenko Sounds good, do you want to send a PR to User Guide?

[MykytaLiashenko]

Yes, let me do this

[ryansully]

While adding an additional CLI argument seems like a simple enough fix, I agree with @mandysimon88 about putting excluded globs into package.json but more like the original comment. If you have multiple globs to exclude, the CLI arguments can result in a very long command. Might it be better to instead have createJestConfig.js in react-scripts read Jest settings from package.json and override the original config? This way NPM scripts could be cleaner, and the config in package.json is set in a way that Jest already expects if you happen to eject your project later on.

Example here:
ryansully@ec18454

Then you can add Jest config to your package.json like so:

"jest": {
  "collectCoverageFrom": [
    "src/**/*.{js,jsx}",
    "!<rootDir>/node_modules/",
    "!<rootDir>/path/to/dir/"
  ]
}

[MykytaLiashenko]

@ryansully Could we add ability to override whole list of options?

[ryansully]

@NikitaLiashenko The code example I provided, as it is written, would only override any previous collectCoverageFrom value specified in createJestConfig.js, so all globs would need to be added to package.json. If that is not desired, the code could always be modified to concatenate or push new globs to the existing config.

[jameschao]

@ryansully - sorry could you clarify about your code snippet? I currently haven't ejected and so do not have such a createJestConfig.js. Do I need to eject in order to use the snippet you provided?

[ryansully]

@jameschao No, you don't need to eject; it is an edit of createJestConfig.js as it is found in a non-ejected project, under the react-scripts package. I don't think createJestConfig.js exists in an ejected project anyway, since Jest config in an ejected project can be read directly from package.json.

As such, any updates to react-scripts that modify createJestConfig.js could possibly break; I wrote it for use in a fork of CRA and didn't submit it as a PR because I'm not sure the project maintainers would accept it as it is (it sort of goes against their Core Idea of avoiding configuration as much as possible). I guess I can submit a PR anyway. It is compatible with a standard Jest configuration for package.json, though, if you do decide to eject your project at a later date.

[jameschao]

@ryansully - oh ok, so you mean directly updating node_modules/react-scripts/utils/createJestConfig.js? Or did you mean using a fork of react-scripts?

[ryansully]

@jameschao Yes to the first question.

[jdickey]

"Zero config" is a great thing until it makes your app or tooling stupid; just ask anybody who's maintained a legacy "The Rails Way" codebase for a few years. Having a core idea that by default you avoid configuration as much as possible is a good thin. A far, far better thing would be to support configuration of things that make sense to a significant share of your user base. This can be hard when you've open-sourced code developed for use in-house that now has a sizable user community out in the wild. That's part of the responsibility you assumed by open-sourcing your tool in the first place.

Yes, having a way to override default configuration is necessary. I really don't care if it's in package.json or src/setupTests.js or wherever, as long as it's there. The alternative is locking people into a configuration that can't change to meet their changing needs. American business has a name for the effects of that; it's called Chapter 7.

Software is far more useful and interesting when it's a tool than a fetish. Deliberately designing your tools so that they can't be customised, or running a project in a way that discourages PRs that solve real user needs, discourages collaboration. Yes, it's great that the tool exists and is open source. But when you have over four times as many forks as PRs over project life or watchers, you may want to ask yourself some hard questions about project governance and direction.

[Timer]

"Zero config" is a great thing until it makes your app or tooling stupid; just ask anybody who's maintained a legacy "The Rails Way" codebase for a few years. Having a core idea that by default you avoid configuration as much as possible is a good thin. A far, far better thing would be to support configuration of things that make sense to a significant share of your user base.

In align with our philosophy, we avoid adding configuration where unnecessary. We do, however, permit configuration when unavoidable.
Remember, this tool is targeted first at beginners, not highly experienced developers.
We do not want to make something that is so complicated to understand that it becomes unwieldy, whereby individuals get lost in the documentation trying to figure something out.
Additionally, we try to care care of matters that pertain to a significant share of our user base first, this is not one of those issues.

We try our best to make this library smart, using an array of heuristics, interactivity, and human-understandable configuration when possible to prevent adding configuration. You can see this in action with our port detection or homepage setting, among other things.

This can be hard when you've open-sourced code developed for use in-house that now has a sizable user community out in the wild. That's part of the responsibility you assumed by open-sourcing your tool in the first place.

We have heard this thread, and many other threads, loud and clear and understand that configuring certain things is highly desirable. We listen to this feedback, and have voiced that we are more than willing to add support for customizing Jest (among other things).
Unfortunately, much of the development of this product is done during free time for its developers and we cannot satisfy these requests as there are other high priority things on our list(s).

Yes, having a way to override default configuration is necessary. I really don't care if it's in package.json or src/setupTests.js or wherever, as long as it's there.

If you would like to help solve this problem, please checkout #1830 or #1941 and comment to get the ball rolling on these topics (in this issue).
Do we want to allow any Jest configuration to be overridden? Do we only want a certain subset? These are just a few questions we have to thoroughly discuss before making any decisions.

The alternative is locking people into a configuration that can't change to meet their changing needs. American business has a name for the effects of that; it's called Chapter 7.

We never lock people into our configuration, and you can eject at anytime if you do not agree with the direction of our project. We also encourage you check out a long list of alternative products, which may better suit your needs.

Software is far more useful and interesting when it's a tool than a fetish. Deliberately designing your tools so that they can't be customised, or running a project in a way that discourages PRs that solve real user needs, discourages collaboration. Yes, it's great that the tool exists and is open source. But when you have over four times as many forks as PRs over project life or watchers, you may want to ask yourself some hard questions about project governance and direction.

We actively encourage contributions using tags , and solve the most important issues first. We try to make CRA a very friendly place to make first contributions.
We also try our best to keep up with pull requests, but realize we do not always meet people's expectations. Sometimes giving your pull request a small bump can go a long way.

As for forks, we actively encourage people to fork the project as an alternative to ejecting and setup automated tools which keep their forks up to date. I'm not really sure how the watchers vs forkers argument is relevant, because most people don't want to be concerned with what's going on behind the scenes. People just want something that works, and works well. They don't care about what goes on in this repo.

Please let me know if you would like to provide and constructive criticism about our practices or directions of the project, and we are happy to discuss them. You seem to have some frustrations which we are willing to try to address.
Also remember that this is a project worked on strictly with free time, and respect some of our limitations.

Thanks!

[gaearon]

Hey, just wanted to chime in to say we appreciate all the discussion here. I’ve been busy with some other things you might be using (React, React DevTools), but going to dedicate some time to Create React App now.

We understand that the request to specifically exclude files from coverage is a reasonable one. We’re not opposed at all to supporting this—just didn’t have the time to address this specific request yet.

Cheers!

[lifeiscontent]

@gaearon is there a way to create a snapshot test of a coverage report within create-react-app?

[gaearon]

Fixed in #1830.

[gaearon]

Please help beta test the new version that includes this change!
#2172

[ancyrweb]

How about using an annotation before the function name, like @codeCoverageIgnore inspired by PHPUnit ?

[viraths]

If you want to ignore any examples folder from coverage.

"jest": {
  "collectCoverageFrom": [
    "src/**/*.{js,jsx}",
    "!**/examples/**"
  ]
}

[beauallison]

This is what I was looking for (node_modules is the default so you need to re-add it)

"jest": {
    "coveragePathIgnorePatterns": [
      "/node_modules/",
      "/test/"
    ]
  }

Reference: https://facebook.github.io/jest/docs/en/configuration.html#coveragepathignorepatterns-array-string

[3dos]

CRA doesn't supports coveragePathIgnorePatterns yet and collectCoverageFrom doesn't seem to work either for me

"jest": {
    "collectCoverageFrom": [
      "src/**/*.{js,jsx}",
      "!/node_modules/",
      "!/index.js",
      "!/registerServiceWorker.js"
    ]
  }

Still gets me index and rsw in the coverage. I know running after a 100% coverage is a misleading goal but still, writing tests for these is something I will not do and would be glad not to see these files in the coverage results.

Is there an easy way to ignore them ?

[kcjpop]

@3dos You missed src in the paths. This works for me:

  "jest": {
    "collectCoverageFrom": [
      "src/**/*.{js,jsx}",
      "!/node_modules/",
      "!src/index.js",
      "!src/registerServiceWorker.js"
    ]
  }

[3dos]

Thanks @kcjpop ! I feel so dumb now. Indeed this works

[jstein-ftdi]

this ignores *.stories.js files for me:

collectCoverageFrom: [ 
    'components/**/*.{js,jsx}', 
    '!components/**/*.stories.{js,jsx}', 
    'pages/**/*.{js,jsx}'
]

[omelniz]

or
coveragePathIgnorePatterns: ['.story.js']

[groundh0g]

I really only needed to exclude two files: index.js and registerServiceWorker.js ...

So, I added /* istanbul ignore file */ to each file (after any import statements).

[kevin-king]

@NikitaLiashenko @robcaldecott Wrapping the collectCoverageFroms, containing an exclamation, in single quotes works for me npm test -- --coverage --collectCoverageFrom=src/**/*.js --collectCoverageFrom='!src/**/*.stories.js'