[Feature]: Option to throttle console.log

[benjaminjkraft]

🚀 Feature Proposal

Jest should have a setting to stop outputting console logs from the test after some number of logs.

Ideally this could be based on the size of the logs (e.g. truncate after 100kb) but it could also be a cruder thing based on number of logs (truncate after 1000 console.log calls). It should output one last log to tell you it's doing this. The limit could be per test case, suite, or run, I'm not sure how much it matters. I could see an argument for setting a high default, or no default but allowing users to do so.

Motivation

We recently had some tests fail nondeterministically because they logged several megabytes of output, so much that they overwhelmed the output pipe in our CI and crashed the test runner with error EPIPE. Of course ideally we should not log so much, but in a larger codebase that's hard to control, and such failures are nondeterministic. So it would be nice to have some ability to truncate! (It might also be nice to wait/retry on EPIPE, but getting that stuff 100% perfect through all stages of the system can be pretty tricky, and it's not like such large logs are usually useful to humans anyway.)

For reference, in our setup the test that caused problems logged about 100k lines comprising 4MB total output.

Example

No response

Pitch

In principle one could write a reporter to do this, but the way the reporters work, it's a bit annoying to patch just that -- you have to copy a bunch of code from the Jest reporters (e.g. duplicate DefaultReporter.printTestFileHeader). What you really want to do is do this in console.getConsoleOutput, or better yet where Jest adds logs to the console buffer (so we don't take up a bunch of memory with logs we'll never use). Actually, it's worse than that: when --verbose is enabled, the logs don't go through the reporter at all, and the Console doesn't seem to be user-configurable. So I don't think it's possible to do this in user-land today. (Perhaps an alternate request is to make that possible.)

Plus, ideally it should (a) be configurable, and (b) apply to all reporters/consoles if so configured, which is probably easier to do in Jest core.