clj-kondo 2021-07-26 | Slack Archive

dorab02:07:50

$ cat test.clj
(ns test
  (:require [clojure.pprint :as pp]))
(pp/pprint "foo")
(comment
  (require 'clojure.pprint)
  )

$ clj-kondo --lint test.clj 
test.clj:7:13: warning: duplicate require of clojure.pprint
linting took 14ms, errors: 0, warnings: 1

I was a bit surprised by this.

borkdude06:07:57

But it isn’t incorrect :-)

dorab17:07:57

Not sure. IMO, commented code should be unchecked for any semantics unless explicitly asked for. Moreover, if I use ; (require ...) or #_ (require ...) instead then there is no complaint from clj-kondo. So, why for the (comment ...) form? I can understand checking to see whether a (comment ...) or #_ (...) block parses, but no checks other than that.

borkdude17:07:56

Because people usually develop in comment forms and it's useful to have linting there.

borkdude17:07:05

You can disable linting in commen forms though, if you want.

dorab17:07:02

Thanks. I see that now. {:skip-comments true}. I specifically looked before I posted, but missed it.

yonatanel08:07:07

Is clj-kondo intentionally ignoring unused required namespaces that don’t use :as or :refer? This test I’ve added to clj-kondo.unused-namespace-test passes, but shouldn’t it fail?

(deftest unused-namespace-simple
  (testing "Ignore plain require"
    (is (empty?
          (lint! "(ns foo (:require [clojure.core.async]))"))))
  (testing "Don't ignore"
    (is (seq
          (lint! "(ns foo (:require [clojure.core.async :as async]))")))))

borkdude08:07:54

this is intentional

borkdude08:07:28

the reason is that people can use this for requiring namespaces with side effects, e.g. loading multimethods or specs

yonatanel09:07:06

Is there a way to configure this behavior, or maybe just a hint for what I can temporarily change in clj-kondo to enable it for some cleanup I’m doing?

borkdude09:07:55

currently there is no config for it

borkdude09:07:24

I would just grep/rg the source for "Unused namespace"

👍 3

lassemaatta10:07:17

I assume the extend-type and extend-protocol macros are not included in the "Clj-kondo only expands a selected set of macros from clojure.core and some popular community libraries."?

lassemaatta10:07:31

or rather: does clj-kondo give any promises on how these macros (and their bodies) are linted?

borkdude10:07:55

if the macro is built into clojure.core then I think clj-kondo should support it

borkdude10:07:10

and if not, there are ways to configure clj-kondo to support custom macros

borkdude10:07:28

e.g. you can lint it as if it was another macro, or implement an expansion yourself

borkdude10:07:17

extend-type and extend-protocol should be supported

lassemaatta10:07:49

borkdude10:07:12