Fork me on GitHub

I there any way to fix the errors given by clj-kondo via command??


I’m working on a project and previously it didn’t had clj-kondo and after adding clj-kondo we found 300+ issues with code. Fixing all of them manually will be pain and time consuming. Is there any other way you can suggest??


@cksharma122 There are several ways to deal with this. I think the easiest one is spitting out the warnings to a file and then diff with that file the next time


And there are plenty of ways to configure clj-kondo, if you want to disable some rules for now:


Reviewdog is one of the tools that can do this diffing as well: but I've never used it.


Another way is using EDN output and then do some scripting on top of that (possibly using babashka)


Hope that helps.


Thanks you @borkdude I’ll try these options


does it make sense to have a lint for get-in used only to extract keywords/functions? It seems like it's just strictly better to use -> for those, being faster and less syntactically noisy


@kevin842 Feel free to post an issue about this so people can discuss. I think an opt-in linter could work. Also, I think you can write a thing like this yourself now using hooks. Example:

👍 3

We already have a related linter, single-key-in, which warns if you use get-in and assoc-in and update-in with a vector with a single key in it


I guess you would then get two warnings about (get-in x [:foo]) - hmm, no, it only should suggest -> when you have more than one key