Clojurians Log v2

does the :refer linter suppport :exclude? I'm running both clj-kondo and joker, and it seems clj-kondo wants me to :refer :all for clojure.test whereas joker wants me to :refer [deftest]...? I would like to not allow :refer in any other cases.

@nicke.claesson Can you lint on the command line with clj-kondo only? This way you will exclude any other linting output from this issue, which is often a confusing factor. And then please ask the question again.

Clj-kondo does not want you to do :refer :all by default (it discourages this for its own analysis good)

for code like this [clojure.test :refer [deftest is testing use-fixtures]] I get test/integration/reconciliation_writer_test.clj:6:27: error: require with :refer

which is fair, becuase I want to disallow usage of :refer because then you don't see that functions are external

however for macros in clojure.test it makes sense to refer them, I think (t/deftest) is unneccessary

OK, I see. The config for this linter is here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#refer and as of now it doesn't support exclusions. But you can ignore the warning locally using #_:clj-kondo/ignore before the form

Feel free to post an issue

I'm more interested in a solution without hacks, so basically you are open to adding the :exclude arg to the :refer linter?

yeah

thanks

@nicke.claesson One thought: since you will probably also add the same namespace to the exclude for the refer-all, maybe we can make it so that the refer linter also uses that config

oh wait, you were not going to do :refer :all, then never mind

exactly, I won't need :refer :all 🙂

Is there an annotation I can add to my rich comment blocks that tells clj-kondo to completely ignore the contents for any checks (I am looking at the docs, but trying to fix a broken build)

yes, #_:clj-kondo/ignore

just place it before the comment form

Awesome, you have unbroken the build 🙂

how about this too? {:skip-comments true} in the config.edn?

That is a good idea, once we update the project to deps.edn 🙂

it's not in deps.edn

it's the configuration for clj-kondo

.clj-kondo/config.edn

Ah, yes, sorry doing many things all at once and all of them are broken 😞

Thinking about this, we only want to skip comments on the build which is done via GitHub actions, so I assume instead of this line in the .yml file

run: lein with-profile test clj-kondo --lint .

run: lein with-profile test clj-kondo --lint --config '{:skip-comments true}' .

yes, you can do that

no

--lint . --config ...

ah, thanks. I'll fix before I push 🙂

is there a way to describe HOFs with clj-kondo? e.g. “function takes a function of :int -> :int”. there is :fn and :ifn, but they don’t have type info or arities, I guess.

no higher kinded types or even generics in the clj-kondo type system currently :)

Hi, first off - thank you for creating clj-kondo :thanks3:. It's amazing project. Quick question on the https://github.com/clj-kondo/config. It looks like the recommended way to lint slingshot is https://github.com/clj-kondo/config/blob/master/slingshot/.clj-kondo/config.edn (or at least that's the only way i got it to work). Does anyone have an example of pulling slingshot as a library instead of the manual copy config ? maybe there is something different about slingshot that prevents us from pulling it as a library ?

{:lint-as { slingshot.slingshot ...} }

@dviramontes if you put the clj-kondo configs library on your classpath and then lint your classpath using:

clj-kondo --lint $(clojure -Spath) --no-warnings

$ clj-kondo --no-warnings --lint "$(clojure -Spath -Sdeps '{:deps {clj-kondo/config {:git/url "<https://github.com/clj-kondo/config>" :sha "e2e156c53c6c228fee7242629b41013f3e55051d"}}}')"

(you might need to update the SHA)

Gotcha, thank you so much @borkdude!

For a CI environment, if I only want to get error level and skip warnings, would I use the --no-warnings flag as a command line argument? I only want the build to fail on error level linting, skipping warnings that are less important. Or would it be more appropriate to specify a particular config file and somehow suppress clj-kondo warnings in that ci-config.edn file? I guess I could create a ci-config.edn with ignores for the rules we didnt want to stop the build for.

@jr0cket The, no --no-warnings argument is only used for populating the cache, so you lint, but you will ignore the warnings

Creating a ci-config.edn is indeed the one you need

given that a library (here: malli) can emit clj-kondo :type-mismatch configs from a namespace x. is there a convention / place where to write the info so it's picked up automatically?

@ikitommi Not really, you can write to any dir inside .clj-kondo and then users can opt in to that config using :config-paths

This is opt-in for safety, since I don't want users to automatically opt-in to hook code, etc

and same question but for the library's own function definitions.

@l0st3d Not really, since I don't think you will catch many errors using static analysis.

Unless you go fully statically typed

same answer applies, I think?

yeah ... you're probably right 😉 ... just wondered how far you could go with that sort of analysis ... like maybe as far as the structural typing type thing, so something like

(->> (range 10)
       (map #(array-map :test %))
       (map #(update % :test str))
       (map #(update % :test inc)))

that's probably a research project ...

there's already such a research project and someone who has a PhD on it: @ambrosebs in #core-typed

yeah ... that's what I meant 😉

If Clojure becomes popular enough, maybe M$FT will make a TypeScript for CLJ? ;)

ha

it's just I feel like having the type system outside of the compiler (like a linter) is just better design ... you don't need to police it, just inform people of possible problems ... and given that freedom, I wondered if it would be easier to get some quick wins in that direction ...

just an idle thought 😉

Kondo complains that do is redundant, is it?!

#?(:clj  (Long/reverseBytes b64)
     :cljs (do
             (.setBigUint64 -data-view
                            0
                            b64
                            false)
             (.getBitUint64 -data-view
                            0
                            true)))

Well, clj-kondo already has a type system, albeit a simple one which catches many things I found annoying myself.

$ clj-kondo --lint - <<< '(take 10 (map inc))'
<stdin>:1:10: error: Expected: seqable collection, received: transducer.

@adam678 This depends on the context

If there is already an (implicit do) around this, then it could be redundant and you can avoid this using #?@

yup ... and I think it's great ... I find it very ... it catches a lot of the stupid mistakes I make every day ... Thank-you so much for releasing it to the world

Right, those forms are the body of a function so I should #?@ indeed to be technically correct. Took me a bit off guard.

could you treat map/`filter` /etc as ->? so that if you can tell what type the elements of the list are, you could turn (map inc (map str (range 10))) into (-> 10 str inc), which could return a warning? ...

Maybe, but probably not low hanging fruit

Does CLJ-Kondo have a way to exclude a namespace from linting ?

@dviramontes Kind of, you can exclude files from the lint output. See https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#include-and-exclude-files-from-the-output

right on! thank you

@ikitommi I am considering a dir structure reflecting the namespaces of the vars being typed if the type output gets too large to read on every clj-kondo startup

But this would only become relevant if people are type annotating lots and lots of functions, which is currently not the case