Loading repository data…
jevakallio / repository
A Jest Reporter to group, hide and prettify spammy console warnings
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
A custom Jest reporter to reduce console spam in your test output.
Remember back in the day when Jest used to swallow console.log messages by default, and it was basically impossible to figure out why your code was failing under test? *Sigh*. Those were the days.
Now that Jest prints all console messages, whether from our own code, third-party framework code, or the test runner itself, we have the opposite problem: It's easy to lose actually important warnings among noise.
The jest-clean-console-reporter reporter collects all console messages written by the test process, and allows you to group them by known error warning types, or ignore them outright.
The best way to remove warnings in your code is to address their root cause.
This reporter is probably best used when filtering out spammy library warnings that are otherwise tricky or impossible to get rid of, or ignoring intentional user-facing warnings of your own project.
Install with your favorite package manager:
npm install --save-dev jest-clean-console-reporter
You'll also need Jest 25.1 or later installed in your project.
// List known warnings you want to group or suppress. See docs below.
// Tip: This is just an array, you can import it from an external file
const rules = [
{
match: /^You are using the simple \(heuristic\) fragment matcher/,
group: "Apollo: You are using the simple (heuristic) fragment matcher.",
},
{
match: /^Heuristic fragment matching going on/,
group: null, // ignore outright
},
{
match: /^Warning: An update to (\w*) inside a test was not wrapped in act/,
group: "React: Act warnings",
keep: true, // include in summary, but also keep raw console output
},
];
// Add reporters to your jest config
module.exports = {
// ...
reporters: [
// Add jest-clean-console-reporter. This takes place of the
// default reporter, and behaves identically otherwise
["jest-clean-console-reporter", { rules: rules }],
// Overriding config.reporters wipes out default reporters, so
// we need to restore the summary reporter.
//
// NOTE: For jest 26.6.1 or older, this file is located at
// @jest/reporters/build/summary_reporter
"@jest/reporters/build/SummaryReporter",
],
};
Pass options to the reporter in your jest configuration as follows:
const jestConfig = {
reporters: [
["jest-clean-console-reporter", options], // <--
"@jest/reporters/build/SummaryReporter",
],
};
const jestConfig = {
reporters: [
["jest-clean-console-reporter", options], // <--
"@jest/reporters/build/summary_reporter",
],
};
options.rulesRules tell the reporter which console messages should be filtered, and how they should be grouped in the summary.
Each rule has three options, match, group and (optionally) keep.
rule.match : RegExp | string | (message, level, origin) => booleanmatch is either a regular expression, a string, or a predicate function:
RegExp: Matches console message against this regular expression.string: Matches console message against this string, first using literal === comparison, and falls back to regular expression comparison using message.match(match). The latter is not recommended, but useful if you need to serialize your regular expressions.match(message, level) where
message is the full console messagelevel is the log level (error, warning, log etc..).origin is the stack trace string for this error. Useful if you want to ignore all errors from a certain library, for example. Note that this string can contain newlines, so any regexes used to match it should use the /g flag.Rules are matched in order, from top down. A message that is not matched by any rule will be displayed in the Jest test output as normal.
Matched messages are grouped according to the group property:
rule.group : string | null | (message, level, matcher) => string | nullgroup is either a string, a formatter function, or null:
string: Matched messages are grouped by this literal stringnull: Matched message is ignored.group(message, level, matcher) where
message is the full console message.level is the log level (error, warning, log etc..).matcher is the original matcher used to match this message. This can be useful if you want to e.g. execute the regular expression for capture groups.null, the message is ignored.rule.keep: booleanSetting keep: true option allows you to keep the original console output for this group intact, while also displaying it in the test run summary.
Define which log levels to display in the summary at the end of the test run:
Default: ["error", "warn", "info", "debug", "log"]
These levels only affect the summary display, and have no effect on whether messages are matched. For that, see Can I ignore all messages of certain log level?.
Here are some questions nobody has ever asked, but might be helpful anyway.
Yes. Use the second parameter passed to a function macher:
{ match: (message, level) => level === "log", group: null }
Yes, but it's probably a bad idea:
{ matcher: () => true, group: null }
Yes, just give them the same group key:
[
{
match: /^Warning: componentWillMount has been renamed/,
group: "React componentWill* deprecation warnings",
},
{
match: /^Warning: componentWillReceiveProps has been renamed/,
group: "React componentWill* deprecation warnings",
},
];
Yes, just set the rule's keep property to true:
{
match: /^Warning: An update to (\w*) inside a test was not wrapped in act/,
group: "An update to (Component) inside a test was not wrapped in act",
keep: true
}
You can use string matchers, which are first compared to the message as literal strings, and failing that, attempted to test against the message as regular expressions:
{
"match": "Warning: An update to \\w* inside a test was not wrapped in act",
"group": "An update to (Component) inside a test was not wrapped in act"
}
You can use the grouping function, where the original matcher is provided as a third argument.
{
match: /^Warning: An update to (\w*) inside a test was not wrapped in act/,
group: (message, _level, matcher) => {
// Note: String.matchAll requires Node 12.x or higher
const [match] = message.matchAll(matcher);
return `React: An update to ${match[1]} was not wrapped in act.`;
}
}
console.errors from a specific library?Yes, console.error comes with an origin property that contains the full stack trace
at the time of logging, which you should be able to use to filter per library, or even per file and line!
The origin may not be available for other log types, so check it before you use it.
{
match: (_message, _type, origin) =>
origin && /node_modules\/rc-form\/lib\/createBaseForm/g.test(origin),
group: 'rc-form validation warnings'
},
Yes, see Contibuting.
This software is very much at alpha stage. If you want to help, here are a few things that could be helpful:
result.console from being printed by the DefaultReporter, so I overrode it. This is annoying, because it can't be used with other custom reporters now. But it occurs to me, that maybe if a custom reporter is installed in the pipeline before the default reporter, perhaps we could filter out console messages there. Tradeoff here would be that we would nuke the console for ALL other reporters, whereas now we only do it for DefaultReporter.rule.failAfter.jest src/file.js), the reporter is not activatedSelected from shared topics, language and repository description—not editorial ratings.
jest-community /
A Jest reporter that creates compatible junit xml files
83/100 healthrickhanlonii /
A silent reporter for Jest
75/100 health3dmind /
A Sonar test reporter for Jest.
reportportal /
Agent to integrate Jest with ReportPortal.
71/100 healthvbfox /
A jest reporter to have test results in BuildKite as annotations
32/100 healthKrizaldiw /
Automation API Testing using Jest, Jest-html-reporters, Chai
31/100 health