📎 Cap console output length when there are many errors

[joukevandermaas]

Description

For performance and usability reasons, it is best not to print too much text to the console when there are many errors. Instead, if the number of errors or the output length is over a certain threshold, either truncate the output or print a summary instead.

I ran this command in a fairly big (but not huge) repo:

rome format .

It took many minutes (almost 10) to print all of the errors on my development PC. I could never act on this many errors at once, and the execution time was completely dominated by printing the errors, rather than finding them. Prettier does not have any errors on this repo, but takes much less time to run (~30s).

In case it matters, I am using windows terminal 1.16.2642.0 on Windows 11 (22621.674). Although this terminal is known to be slow, I suspect this would also be an issue on other terminals and operating systems.

Note: the output itself is very good, I am not suggesting to reduce it or change it any way for the common case of only a few errors.

PS. I was on the fence between "bug" and "task" categories. I'm sorry if I picked wrong, this seemed to fit neither category that well.

[leops]

Thanks for the report. This is actually a bug, the CLI does have a cap for the number of diagnostics it's allowed to print (set with the --max-diagnostics CLI argument, defaults to 200) but the format diff diagnostic is mistakenly not being counted correctly.

[sebmck]

I think we can do some work on improving truncating individual diagnostics too. IIRC a diff for a file would be counted as a single diagnostic and would show every single line if something like indentation changed. We could cap showing the diff to a certain amount of lines.