Collapse output to 20 items

[daniilsapa]

Closes #51

The solution is still raw and it's an early PR, so you can see the general approach and we can clarify some details.

1. When I was working on this logic I came across a thought that we probably need to make the number we collapse diagnostics to configurable and introduce a new config object type for such things that configure Steiger itself (it is very likely that other options will appear pretty soon) and not severities/options for rules. It seems it's better to introduce such a new object type earlier, e.g. in the next minor update.
2. Should we introduce severity to consideration when we collapse diagnostics? Looks like we need to count error first because it's the thing that breaks CIs or local checks. It would be quite annoying if you do not see an error because the quota is exceeded with warnings
3. It looks like runRules from app.ts needs to return some Report interface, so it contains not just diagnostics but also some meta info about them. We need this to display the number of shown vs hidden diagnostics etc. other fields may appear in the future.

[changeset-bot]

🦋 Changeset detected

Latest commit: f3b4263

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@steiger/pretty-reporter	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[illright]

Interesting considerations, thanks for the early update! I looked at the code and realized that I forgot to mention one important detail in the issue description.

I originally envisioned this as a purely cosmetic thing rather than a linter feature, and as such, I planned that this functionality would be added to the pretty reporter rather than the linter core. This way, all reporters get the same full diagnostics, but some reporters might choose to hide some.

The inspiration for this feature came from Biome, they also have a 20-diagnostic limit. Here's how they show it:

That's why I don't think we should make this thing configurable or even disable-able. If one wants to see all diagnostics, I think it's not because they want to read all of them individually. For mass-reading of diagnostics, the JSON reporter is probably better. I suggest we write "X diagnostics were hidden, run with --reporter json to see all diagnostics" or something.

The severity consideration is a very good point, I agree that we probably want to sort the errors first and then, if there's space left, print warnings too. If there's a rule that has produced only warnings, then we only print its diagnostics if all the errors have been printed.

[daniilsapa]

Oh, yeah, actually it makes sense to make it a cosmetic thing and move pretty-reporter. It would also make the implementation easier and the resulting codebase less complex. Do you like the general approach? If so, I will move the logic to pretty-reporter, add severity to consideration, and refactor it a bit.

[illright]

Overall the code looks good, I only have minor concerns about over-abstracting — such as having an entire feature for this, and also making the quota a modifiable parameter. Seems like the code could be simpler by keeping it all in one function

[daniilsapa]

@illright
I've moved the solution to pretty-reporter. Also, you can see the output here:

Let me know if you think we must rephrase/change it somehow

[daniilsapa]

The bundle size pipeline fails when the git branch contains slashes. I'll fix the problem as part of this issue

[illright]

Thanks for noticing the bundle size workflow issue, my mistake! I think we can replace everything that isn't /[0-9a-zA-Z-._]/ (ref) with - to overcome this.

The solution is good overall, but slightly hard to understand, I made some suggestions to improve clarity, let me know what you think

[daniilsapa]

It looks like I fixed all the issues, please review when you have time

[illright]

Yep, now the code is good! There is one potential issue in the workflow, and I figured I'd also throw in a little non-blocking suggestion as well

[illright]

Okay, this seems good to go!

[pkg-pr-new]

Open in Stackblitz

npm i https://pkg.pr.new/feature-sliced/steiger@160

npm i https://pkg.pr.new/feature-sliced/steiger/@feature-sliced/steiger-plugin@160

npm i https://pkg.pr.new/feature-sliced/steiger/@steiger/toolkit@160

commit: f3b4263