Clojurians Log v2
clj-kondo
@epransky I've been working on a way to share hooks across projects. Coincidentally, mount comes up a lot (popular library!). If your .clj-kondo directory ends up being public, I'd love to try adding those hooks to other projects.
Great, thanks! I'll add this hook to my tests. Appreciate it!
can you link me to the project? ill contribute there
hey @epransky, sorry for taking so long to respond. The project repo is here: https://github.com/atomist-skills/clj-kondo-skill but it probably requires a bit of explanation.
The idea is to allow users to attach clj-kondo to their GitHub pushes. It produces annotated GitHub checks and ideally, makes it easy to share configuration (including hooks) across Clojure projects. On most projects, especially new ones, we want clj-kondo checks to be there by default.
However, it's actually been quite a challenge to roll this out to existing clojure projects without spending some time doing some analysis of the violations, and preparing teams. One of the big challenges is that you need hooks (like your mount example) to be ready to add to all of the projects that use mount!
We experimented with a few things: • only neutral checks - don't break the build until you've had a chance to work on the violations. However, the number of annotated violations can impact the usability of PRs! • don't publish annotated violations until you've at least cleared the violations in the project once, and then turn them on to help keep them at zero? And the hypotheses is that one thing we can do to be prepared to help people take advantage of this is to be ready with a good starting configuration, including hooks.
So when I configured this across our team's repos, I included a reference to your gist, so that it merged your config and hooks into all of the clj-kondo run across all of our Repos.
You're welcome to use this on your repos if you want to try it out. It requires that you enable our GitHub app, but it's free to use.
ok, ill have a look. thanks for the explanation!
Cool, and if you want to enable it on a Repo, you'll actually need to do 3 things: • signup with GitHub https://go.atomist.com/user/signup • enable our GitHub app (on at least a few Repos in one of your Orgs) https://go.atomist.com/r/auth/manage/integrations/add/GitHubAppResourceProvider • and then enable this clj-kondo function to run: https://go.atomist.com/catalog/skills/atomist/clj-kondo-skill The config where you can add your gist url is called "Custom configuration URL" (probably not a great name)
Is there some kind of option for cljc files that it only shows imports as unused if they actually are unused, and not just unused by the clj part?
clj-kondo lints a .cljc file twice: once for clj and once for cljs
Hmm so I figure that'd be something for the flycheck plugin to "fix" then? It's just... I really enjoy having clj-kondo, but having your file littered with "unused import" and "unused argument" warnings is a tad annoying. How do people usually deal with that scenario?
to answer your question: that option does not exist and the reason for it is the way .cljc files are processed (similar to how they are processed in Clojure itself)
Yea, it makes sense to have it linted twice, once for each "mode"
you can turn off that linter for that namespace locally, using metadata config. it's implemented, but not yet released, see: https://github.com/borkdude/clj-kondo/issues/932
I actually like the way clj-kondo handles .cljc and I tend to fix all warnings by marking unused bindings for one branch with _foo and the other one with foo.
How do you handle function args when the function body is split? Having #? inside the arg vector seems very messy
if you find that too messy, you can duplicate the entire arg vector once for clj and another time for cljs, but I tend to choose the inline version.
I'm afk now, sleep
Okay. Thanks!