feat: add --quiet CLI option

[Kedlingar]

What changed

Adds a --quiet CLI option that suppresses warning diagnostics from reporter output while preserving errors.

Behavior

1. steiger ./src --quiet reports errors only
2. warnings still participate in --fail-on-warnings
3. warnings are still processed by --fix
4. --quiet works with both pretty and json reporters

Testing

Added integration tests covering:

1. errors and warnings with --quiet
2. warning-only diagnostics
3. --quiet --fail-on-warnings
4. JSON output

Motivation

This makes it possible to use warnings for advisory rules while keeping normal CLI output focused on errors.

[changeset-bot]

🦋 Changeset detected

Latest commit: ee12228

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

This PR includes changesets to release 2 packages

Name	Type
steiger	Minor
@steiger/integration-tests	Patch

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

[Solant]

Hey 👋

Thanks for taking time and contributing to the project!

I have some concerns regarding the test implementation and the flag itself. I'll mark this PR with "Request changes", but don't change the implementation yet. Can you tell me a bit about what you want to achieve and why do you need this feature?

[Kedlingar]

Hey 👋

Thanks for taking time and contributing to the project!

I have some concerns regarding the test implementation and the flag itself. I'll mark this PR with "Request changes", but don't change the implementation yet. Can you tell me a bit about what you want to achieve and why do you need this feature?

Hello! Thanks for the review!

Yes, you're right, the idea is partly inspired by Eslint's --quet option, but my primary use case is a bit different from simply disabling unwanted rules.

In my project, some rules are intentionally set as 'warn'; they represent useful architectural issues that I still want to see during a normal Steiger run, but which aren't currently blocking development.

With --quiet, I was trying to ensure that only errors are displayed for each call, without changing the overall project configuration or disabling these rules entirely.

I believe that Steiger's configuration and --quiet solve different problems.

However, I agree with you that the interaction with --fail-on-warnings is a bit confusing. If that makes sense, I think it's possible to make --quiet and --fail-on-warnings mutually exclusive.

I also agree with the concerns about the integration test. If we can discuss the desired CLI behavior, I can rework the test.

In short, I need a way to temporarily output only errors, while still being able to configure warnings, rather than permanently disabling rules.

[Solant]

Ok, this makes sense. I like the idea of making those flags mutually exclusive to prevent silent errors. A couple of suggestions:

• [optional] We could try renaming this flag from --quiet to --ignore-warnings or something similar so it can have parity with the mutually exclusive --fail-on-warnings
• I think the current test is very sophisticated and fragile, so it is better to make it inline with the existing kitchen sink app. This can be a bit cumbersome, so if you think it takes too much time to implement it, feel free to skip the testing part for now

[Kedlingar]

Ok, this makes sense. I like the idea of making those flags mutually exclusive to prevent silent errors. A couple of suggestions:

• [optional] We could try renaming this flag from --quiet to --ignore-warnings or something similar so it can have parity with the mutually exclusive --fail-on-warnings
• I think the current test is very sophisticated and fragile, so it is better to make it inline with the existing kitchen sink app. This can be a bit cumbersome, so if you think it takes too much time to implement it, feel free to skip the testing part for now

Thanks for the feedback! I've updated the pull request.

1. Renamed --quiet to --ignore-warnings.
2. Made --ignore-warnings and --fall-on-warnings mutually exclusive.
3. Reworked the tests to use real data.
4. Added Windows and POSIX snapshots.
5. Updated the documentation and changeset.

I'm not entirely sure if I implemented the tests correctly; I followed the smoke test example.
If you also noticed any errors in the process of my creation and work with the pull request, please provide feedback, I would be very grateful! (I'm new to this, but I'd like to learn how to properly assist in tool development.)

[Kedlingar]

There was an error with the tests, I tried to fix it.

[Solant]

Yeah, those tests are a bit of a pain to work with 🥲

I can suggest you try to run them locally in both Windows (via CMD, not powershell) and Linux/MacOS. But if it is too troublesome, feel free to remove the test for this flag completely. This change is relatively small, so I think it is ok to add those tests later.

[Kedlingar]

Now the test seems to be running successfully. I literally increased the timeout to 15 seconds, but the existing smoke test is now exceeding the default timeout by 37 ms...
What should I do in this case, and is increasing the timeout even correct? Are there other, more correct solutions?

Tests sometimes behave very strangely. I had a similar situation: the execution took over 5 seconds, and then it completed in less than a second :))

As far as I know, they run in parallel. Perhaps, as an option, I should change them to run sequentially using fileParallelism: false? What do you think?

[Solant]

Sure, we can try longer timeouts and/or different parallelism strategy

We'll definitely need to check how to make those tests more stable

[Kedlingar]

Sure, we can try longer timeouts and/or different parallelism strategy

We'll definitely need to check how to make those tests more stable

Okay, I'll come back to this question when I have some free time :)