report blacklist

[thumbnail]

Context

Sometimes a lint-warning won't need fixing (because edge cases, dev preference, etc.) We want to have a way to ignore recurring warnings from bothering the user.

the CI integration (#88) would need this, so the build does not fail and the warning is considered unimportant.

Task

1. create a extensible blacklist
2. ignore reports matching the blacklist

possible approaches

1. a simple edn list with the :line, :column, :filename, and :source of all (to be) ignored reports
   • con: if the location of the warning changes, the ignore list has to be updated
   • we can automatically check whether all ignores are still triggered.
2. metadata, by tagging a form with ^:formatting-stack.<linter>/ignored.
   • moving the form doesn't break whitelist
   • self describing. it's right in the source.
   • con: clutters code with metadata irrelevant for the behavior of the program itself.
   • con: implementation might be more complex, as the violated form is not available in the reporter right now. Not all linters parse the source

• con: not all reports address one specific form. e.g. loc-per-file, and one-resource-per-ns

[vemv]

If the CI integration was analog to https://github.com/DeLaGuardo/clojure-lint-action , namely applying a diff over a PR's changes only, maybe https://github.com/nedap/formatting-stack/issues/132 wouldn't be that necessary.

As of lately, I'm thinking that a big CI step that analyzes the whole project is bound to be a nuisance to people, as always unrelated stuff will show up.

Requiring people to configure f-s seems not particularly attractive either.

(We can refine a https://github.com/DeLaGuardo/clojure-lint-action -like idea in a separate issue)

[thumbnail]

If the CI integration was analog to https://github.com/DeLaGuardo/clojure-lint-action , namely applying a diff over a PR's changes only, maybe #132 wouldn't be that necessary.

This issue overarches the CI issue because also (new) devs shouldn't be bothered by acknowledged / allowed warnings anyway. The main goal of this issue is to address unnecessary noise during development on (big / legacy) projects.

'm thinking that a big CI step that analyzes the whole project is bound to be a nuisance to people, as always unrelated stuff will show up.

I don't think so. If we can create a good blacklist which doesn't require a lot of maintenance etc., we can prevent this issue altogether, and keep the CI integration simple (exit with (+ (count warnings)))

Requiring people to configure f-s seems not particularly attractive either.

The configuration would be additional, to allow more fine grained control over the output.

[vemv]

Given that by now, both clj-kondo and eastwood offer their own ignore 'syntaxes', f-s users can simply specify those and f-s will forward them to the underlying linters accordingly.

That might be sufficient to consider this issue solved?

There are more linters, but those don't emit false positives (as they tackle very tiny domains) so generally there's nothing to ignore.

[thumbnail]

I think the priority is lower since the biggest linters ship with good ignore syntax nowadays. However I think a way to ignore built in linters is required before this issue can be closed