This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-06
Channels
- # announcements (1)
- # babashka (7)
- # beginners (93)
- # bristol-clojurians (1)
- # cider (7)
- # clj-kondo (42)
- # cljs-dev (9)
- # clojure (67)
- # clojure-europe (4)
- # clojure-france (4)
- # clojure-germany (2)
- # clojure-italy (3)
- # clojure-nl (10)
- # clojure-uk (62)
- # clojurescript (11)
- # clojurex (3)
- # conjure (77)
- # cursive (16)
- # datomic (105)
- # docker (4)
- # editors (3)
- # events (5)
- # fulcro (34)
- # jobs (1)
- # juxt (7)
- # kaocha (7)
- # lambdaisland (3)
- # lein-figwheel (2)
- # leiningen (19)
- # malli (14)
- # meander (6)
- # mid-cities-meetup (6)
- # off-topic (20)
- # pedestal (2)
- # reagent (17)
- # reitit (7)
- # remote-jobs (1)
- # shadow-cljs (17)
- # spacemacs (23)
- # specter (2)
- # tools-deps (34)
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 https://github.com/borkdude/clj-kondo/blob/master/doc/config.md)
@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...
{:linters
{:consistent-alias
{:aliases
;; 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}}
:lint-as
{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...
it was this issue https://github.com/borkdude/clj-kondo/issues/800
it was this issue https://github.com/borkdude/clj-kondo/issues/800
I'll look at it, again. I see we didn't add a proper unit test for that case last time š.
@jumar yes, yes and no (https://github.com/borkdude/clj-kondo/issues/736)
Great, thanks! Do you know if there's a workaround when using it in an editor (Spacemacs)?
I'm not sure what you are referring to since you brought up three different questions
flycheck-clj-kondo accepts extra arguments you can pass to it.
https://github.com/borkdude/flycheck-clj-kondo/blob/f652a8dc4cff01e78bba50b555bae7ba6115b552/flycheck-clj-kondo.el#L68
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
@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.
@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 https://github.com/borkdude/carve š
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
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.
(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
).