Fork me on GitHub

I haven't been watching clj-kondo for a while but it looks it's getting better and better all the time - great work! 🙂 I have a few questions regarding project setup • Do I still need to create .clj-kondo directory manually? could that be created automatically instead? (I guess I often forget to do this for a new project) • How often, in practice should I clj-kondo --lint "<classpath>" ? Should I re-run it after adding a new dependency? • Would it make sense to have a global ~/.clj-kondo/config.edn for default configuration shared by all projects? (I haven't found an equivalent to this option in


@jumar While that latter sounds appealing, it undermines repeatability -- if the only configuration is per-project, then that config can be checked into git with the rest of the project and anyone else working with the project gets the same clj-kondo config.


Oh, that's right. I'm mostly interested in linting projects where others are not (yet) using clj-kondo. Or perhaps have really a default for every project (including personal projects) and then, perhaps later, provide specific configurations for team projects.


I've started seeing .clj-kondo/config.edn in more and more projects lately so...


Would you mind sharing yours?


   ;; straw man for some standardization:
   {clojure.string str,
    com.stuartsierra.component component,
    next.jdbc jdbc, next.jdbc.result-set rs, next.jdbc.sql sql,
    ring.util.response resp}}

  :missing-docstring {:level :warning}

  :single-key-in {:level :warning}

  :unsorted-required-namespaces {:level :error}}

 {expectations.clojure.test/defexpect clojure.test/deftest}}
 ;; I'm not sure whether we want to skip (comment,,,) forms or not...
 ;; ...having it flag def for having no docstring is kind of annoying
 ;; but having it flag all sorts of other things in (comment,,,) is useful
 ;; :skip-comments true}


I've removed the World Singles specific stuff -- and this is just the start of what I expect to be in there over time...


I haven't spent much time configuring it for Expectations so I'm still seeing a lot of warnings and errors in our test suite. I suspect that will require quite a bit of work since there are some... interesting... macros there that add some unusual syntax...


warning: Missing docstring is back on deftype in yesterday release...


@serioga Hm, that is a regression for fixing a problem seancorfield had.


I'll look at it, again. I see we didn't add a proper unit test for that case last time 😕.


Great, thanks! Do you know if there's a workaround when using it in an editor (Spacemacs)?


workaround for what?


I'm not sure what you are referring to since you brought up three different questions


Having global config and using --config


flycheck-clj-kondo accepts extra arguments you can pass to it. so if you call that function with "--config" "..." in your emacs setup, that will be given to clj-kondo.


I can't speak about spacemacs since I'm not using it, but this is just a regular elisp package which you should be able to call


Thanks, that should work!


@serioga Issue fixed (again) on master. If you want I can provide you with a link to a new binary, or you can build your own. Since I just released it's going to a few weeks until the next one I think.


Thank you. Release is not necessary, I can wait :-)


@borkdude Some time this week I'm going to carve out a couple of hours to look more deeply at clj-kondo and Expectations (specifically the clojure.test-compatible version) and see what I can configure and what I need assistance with (or, perhaps, enhancements to clj-kondo for).


Part of the issue is that Expectations has some syntactic constructs that seem hard to deal with, but I need to do deeper analysis to figure out exactly what action to take to get clj-kondo to be happy with them. The primary one I've seen but not yet spent time on is more-of which takes as its first argument a form which is essentially a destructuring: (more-of {:keys [a b c]} expected actual expected actual,,,)


So there's nothing in Clojure to "lint as" and I'd still like the body to be analyzed...


@seancorfield When I read the notification on my phone I thought you were talking about 🙂


Yeah, weird macros are an ongoing problem. I've been playing around with the idea to let people provide a standin function in their config and let the Small Clojure Interpreter transform the expression using that function to something known, but that's something that won't land any time soon I think, if it ever will


so for now the best we have is :lint-as and :unresolved-symbol + :exclude


I hope in time that we have enough macro's that people can use lint-as for, but there's always exceptions


It certainly encourages people to think more carefully about the syntax of macros they add to libraries 🙂


The whole with*transaction thing in the JDBC libraries comes about purely because they are macros that introduce syntax that isn't really like anything else in Clojure (in their case a "binding" form that can have three expressions -- something I would change if I were to do-over).


if someone can provide support for expectations, maybe those can be transformed into deftest-like expressions. clj-kondo has support for detecting missing assertions which you would then also get. I'm not familiar with expectations myself. is it widely used?


It is not. There are two flavors: "classic" Expectations which uses unnamed tests and runs them all by default at JVM shutdown and therefore has all sorts of Expectations-specific tooling; and the new version which uses named tests so it can be clojure.test-compatible but still retain a lot of the compact syntax from the classic version.


I maintain both so, worst case, I will end up submitting PRs to clj-kondo to add support for these things.


It's made somewhat more complex by the fact that really only defexpect and expect are macros -- the rest, while they also exist as macros, are just special symbols that expect knows about.


hmm, those kind of macros are especially nasty to lint yes


(they exist as macros so it's easier to show docs for them and it might be easier to integrate into other tooling)


maybe you can write a third version of expectations that has the same syntax has deftest, or similar to other macros 😉


I'll see what falls out of my work with clj-kondo and our test suite this week...


Analyzing more-of in Expectations is very, very close to analyze-as-> (just without the as-expr at the beginning). So far, everything else I've looked at with clj-kondo seems to analyze pretty much out of the box.


from-each can be linted as clojure.core/for. more-> would need a custom analyzer as well (hmm, it would be very, very similar to cond-> except it doesn't have a start-expr).