This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-12
Channels
- # announcements (2)
- # aws-lambda (2)
- # beginners (402)
- # berlin (2)
- # calva (21)
- # cider (8)
- # clj-kondo (31)
- # cljdoc (1)
- # cljsrn (42)
- # clojure (43)
- # clojure-berlin (2)
- # clojure-dev (21)
- # clojure-europe (4)
- # clojure-hamburg (1)
- # clojure-italy (37)
- # clojure-nl (7)
- # clojure-spec (50)
- # clojure-uk (121)
- # clojurescript (46)
- # component (49)
- # data-science (1)
- # datomic (60)
- # emacs (29)
- # fulcro (43)
- # hoplon (5)
- # jackdaw (7)
- # joker (19)
- # luminus (5)
- # off-topic (28)
- # om (2)
- # re-frame (27)
- # reitit (7)
- # remote-jobs (15)
- # rewrite-clj (17)
- # shadow-cljs (95)
- # spacemacs (34)
- # sql (9)
- # tools-deps (17)
- # xtdb (70)
Is there some ready support or should I just use the API in a clojure.test to ensure no warnings are given?
@tatut there are already people using kondo in CI. apart from using a JVM, you can also call the binary and check the exit codes in a script for example
you can also use JSON output and feed it to jq
to script whatever you want, without using a JVM
(deftest lint
(let [result (clj-kondo/run! {:lint ["src/clj" "src/cljs" "src/cljc"]})
{:keys [error warning]} (:summary result)
ok? (= 0 error warning)]
(is ok? "No lint warnings")
(when-not ok?
(clj-kondo/print! result))))
weird, I’m getting a parse error “no conversion to symbol” in one file, but it doesn’t seem to contain anything out of the ordinary… looks like it’s coming from the reader, not kondo though
looks like a namespaced map problem, if I have #:some.ns {:key "foo"}
map in a cljs file, the parsing fails
@tatut can you create a small repro foo.clj
so when calling clj-kondo --lint foo.clj
you get this problem?
it doesn’t seem to occur in the command line tool, only when running from my project jvm… perhaps I’m getting some wrong version from my other deps
hm, is another library of yours also using clj-kondo? I made a patch, for this in rewrite-clj but I’m not calling that patch in the JVM version
see: https://github.com/xsc/rewrite-clj/issues/54#issuecomment-493038733 it’s an issue in rewrite-clj
requiring clj-kondo.impl.rewrite-clj-patch
before calling clj-kondo should resolve the issue
I think I should move that require from clj-kondo.main to clj-kondo.core, but it might interfere if people already use rewrite-clj in their projects
I think eastwood had the same trouble with dependency clashes when people used that in their JVM so they inlined all the deps. Maybe I should do that with rewrite-clj, but I don’t know how that works license-wise
made an issue for this here: https://github.com/borkdude/clj-kondo/issues/254