Fork me on GitHub
#clj-kondo
<
2021-02-19
>
Niklas14:02:22

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.

borkdude14:02:38

@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.

borkdude14:02:37

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

Niklas14:02:24

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

Niklas14:02:53

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

Niklas14:02:31

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

borkdude14:02:58

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

borkdude14:02:29

Feel free to post an issue

Niklas14:02:32

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

borkdude14:02:52

@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

borkdude14:02:21

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

Niklas14:02:14

exactly, I won't need :refer :all πŸ™‚

practicalli_john14:02:13

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)

borkdude14:02:14

yes, #_:clj-kondo/ignore

borkdude14:02:39

just place it before the comment form

practicalli_john14:02:09

Awesome, you have unbroken the build πŸ™‚

dharrigan14:02:20

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

practicalli_john15:02:06

That is a good idea, once we update the project to deps.edn πŸ™‚

dharrigan15:02:11

it's not in deps.edn

dharrigan15:02:18

it's the configuration for clj-kondo

dharrigan15:02:25

.clj-kondo/config.edn

practicalli_john15:02:35

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

practicalli_john15:02:47

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 .
we can add the config like this to the .yml file
run: lein with-profile test clj-kondo --lint --config '{:skip-comments true}' .
I guess if I run it I will find out πŸ™‚

borkdude15:02:00

yes, you can do that

borkdude15:02:16

--lint . --config ...

practicalli_john15:02:59

ah, thanks. I'll fix before I push πŸ™‚

ikitommi15:02:23

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.

borkdude15:02:20

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

πŸ‘Œ 1
l0st3d20:02:12

That would be a pretty great feature though ... is it on your hit-list??

dviramontes17:02:51

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 ...} }

borkdude17:02:45

@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
while you also have a .clj-kondo directory, then clj-kondo will copy the config and it will also propose how you can activate it.

borkdude17:02:52

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

borkdude17:02:02

(you might need to update the SHA)

dviramontes17:02:27

Gotcha, thank you so much @borkdude!

practicalli_john17:02:09

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.

borkdude18:02:21

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

borkdude18:02:46

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

πŸ‘ 1
ikitommi19:02:48

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?

ikitommi19:02:12

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

borkdude20:02:47

same answer applies, I think?

borkdude21:02:11

@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

borkdude21:02:37

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

borkdude19:02:36

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

borkdude19:02:04

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

πŸ‘Œ 1
l0st3d20:02:12

That would be a pretty great feature though ... is it on your hit-list??

borkdude20:02:13

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

borkdude20:02:32

Unless you go fully statically typed

l0st3d20:02:04

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)))
would give an error ... but you're probably right, it's probably way more effort than it's worth πŸ˜‰

l0st3d20:02:49

that's probably a research project ...

borkdude20:02:20

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

l0st3d20:02:00

yeah ... that's what I meant πŸ˜‰

borkdude20:02:12

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

l0st3d20:02:02

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 ...

l0st3d20:02:22

just an idle thought πŸ˜‰

Helins20:02:49

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)))

borkdude20:02:09

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.

l0st3d20:02:28

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

l0st3d20:02:17

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? ...

borkdude20:02:32

Maybe, but probably not low hanging fruit

borkdude20:02:30

@adam678 This depends on the context

borkdude20:02:21

If there is already an (implicit do) around this, then it could be redundant and you can avoid this using #[email protected]

Helins20:02:12

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

dviramontes21:02:11

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

dviramontes21:02:20

right on! thank you