-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
How to exclude some files and folders from coverage report? #1455
Comments
OK, I needed to ignore all 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. |
@robcaldecott |
Can I override the value for the Jest config option in another way? |
How about adding the command to an npm script in your package.json? Does that work with bash? |
It works. Thanks. |
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?
|
@mandysimon88 |
This is commonly requested & we should support this. |
We could just add whole list of possible variants to documentation. |
@NikitaLiashenko Sounds good, do you want to send a PR to User Guide? |
Yes, let me do this |
While adding an additional CLI argument seems like a simple enough fix, I agree with @mandysimon88 about putting excluded globs into Example here: Then you can add Jest config to your "jest": {
"collectCoverageFrom": [
"src/**/*.{js,jsx}",
"!<rootDir>/node_modules/",
"!<rootDir>/path/to/dir/"
]
} |
@ryansully Could we add ability to override whole list of options? |
@NikitaLiashenko The code example I provided, as it is written, would only override any previous |
@ryansully - sorry could you clarify about your code snippet? I currently haven't ejected and so do not have such a |
@jameschao No, you don't need to eject; it is an edit of As such, any updates to |
@ryansully - oh ok, so you mean directly updating |
@jameschao Yes to the first question. |
"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 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. |
In align with our philosophy, we avoid adding configuration where unnecessary. We do, however, permit configuration when unavoidable. 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.
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).
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).
We never lock people into our configuration, and you can
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. 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. Thanks! |
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! |
@gaearon is there a way to create a snapshot test of a coverage report within create-react-app? |
Fixed in #1830. |
Please help beta test the new version that includes this change! |
How about using an annotation before the function name, like |
If you want to ignore any examples folder from coverage.
|
This is what I was looking for (
Reference: https://facebook.github.io/jest/docs/en/configuration.html#coveragepathignorepatterns-array-string |
CRA doesn't supports
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 ? |
@3dos You missed "jest": {
"collectCoverageFrom": [
"src/**/*.{js,jsx}",
"!/node_modules/",
"!src/index.js",
"!src/registerServiceWorker.js"
]
} |
Thanks @kcjpop ! I feel so dumb now. Indeed this works |
this ignores *.stories.js files for me:
|
or |
I really only needed to exclude two files: index.js and registerServiceWorker.js ... So, I added |
@NikitaLiashenko @robcaldecott Wrapping the collectCoverageFroms, containing an exclamation, in single quotes works for me |
I am trying to exclude some JS files from coverage report.
I have already added this to package.json
Unfortunately files from those dir still appear when I run
CI=true npm test -- --coverage
The text was updated successfully, but these errors were encountered: