[gorgoiler]

Love it! …but of course I’d worry about a diff that added one offense while removing another, leaving the net sum the same. Perhaps the author handles this? You want to alert on the former and praise on the latter, not have them cancel out through a simple sum. Admittedly it’s a rare sounding edge case.

The more trad technique for this would be to mark the offending line with # noqa or # ignore: foo. Another way is to have a .fooignore file but those are usually for paths or path globs to ignore.

I like the author’s idea[1] of having the “ignore” mechanism next to the linter codebase itself, rather than mixed in with the production codebase. Adding the files and line numbers for known-offenders to that code could be a useful alternative to a simple sum?

Perhaps more robustly, some kind of XPath like AST syntax to indicate which parts of the codebase have the known problem? It feels just as fragile and could quickly get over complicated.

At the end of the day an online comment has always done it for me. With Python, Meta’s libcst is an excellent and fast way to get an AST that includes comments. It’s the most robust tool I’ve found but you can just use built-in ast.py and ad-hoc file:line parsing too.

https://github.com/Instagram/LibCST

[1] Sorry to be a fanboi but Antimemetics is amazing!

https://qntm.org/fiction

[Normal_gaussian]

This is exactly the issue I bumped into eight or so years ago. I had a ratchet style job that would maintain a file of all of the type issues in the system. Add one, remove one was very common - particularly when it amounted "transform one" so the error change is all on the same line. Note that this is compounded by the errors often showing up quite far away from the code change.

I ended up using something similar to `// @ts-ignore` which would encode a truncated hash of the error message on the line, as well as a truncated hash of the lines AST; the original error message and the justification.

These were long lines so were a PITA, but they immediately had this 'ratchet' effect.

I tried several times to move to a central file referencing the issues, but the complexity in maintaining the references with common refactors was a blocker.