Fork me on GitHub
#clj-kondo
<
2023-06-14
>
Mateusz Mazurczak08:06:48

When I do: clj-kondo --lint . it finds 0 warnings But when I do it on specific directory like: clj-kondo --lint bb/ It finds the warning. Same when I do it on specific file that the warning should be in: clj-kondo --lint bb/src/core.clj It finds warning. Any idea why?

Mateusz Mazurczak08:06:28

馃槥 Any idea how to debug it? When I do clj-kondo --debug it prints the namespace, so it is scanned. And I'm on the newest clj-kondo version

Mateusz Mazurczak08:06:43

clj-kondo v2023.05.26

borkdude08:06:48

can you make a small repro as a github repo, then I could try it locally

Mateusz Mazurczak09:06:42

Okay we've found the error. The problem is we had: bb/src/core.clj docker_images/gha/src/core.clj And that was causing the issue that there were two files with the same namespace.

Mateusz Mazurczak09:06:09

There was no warning that the same namespace was defined twice from clj-kondo

borkdude12:06:57

Not sure if it's a good idea yet, but how would people feel if clj-kondo supported this:

(defn foo [^:clj-kondo/long x] (inc x))
(foo "foo") ;; type error
It seems those hints can live aside normal type hints like ^String ^:clj-kondo/string x

imre12:06:58

Interesting. What is the problem this is supposed to solve?

borkdude12:06:11

getting more type errors through static analysis. but having these annotations littered over your code might not be so nice

imre12:06:46

And what's the benefit of these over normal type hints?

borkdude13:06:04

well, ^String technically means nullable string, since the string may be null

borkdude13:06:21

and writing :clj-kondo/list might be a bit nicer than ^java.util.List x

jeroenvandijk13:06:10

Are type hints like that or presence of destructuring already used as input to clj-kondo?

jeroenvandijk13:06:34

oooh, good to know

borkdude13:06:03

鉂わ笍 2
borkdude13:06:16

since september 2019 or so ;)

馃檲 2
borkdude13:06:32

"presence of destructuring" not sure what you meant with this. presence of destructuring doesn't mean that the input it always a map, since technically it's safe to call get on anything

jeroenvandijk13:06:30

That鈥檚 true, but I personally never use destructuring when I would want to put something else there. So I think I would appreciate the possibility of using this information on my projects when I make a mistake. For instance I would consider it a bug if I feed a string to something where I am using destructuring

馃憤 2
imre13:06:38

So this could serve as additional metadata to narrow the requirements for an argument?

馃憤 2
imre13:06:14

Sounds similar to what one would use spec or malli for, for example

borkdude13:06:56

Yes. You can already use malli to accomplish the same. https://github.com/metosin/malli#clj-kondo But not everybody wants to bring in malli or something else to their libraries

borkdude13:06:19

Perhaps a more general library agnostic scheme could also be useful, that malli and clj-kondo and .. could agree upon.

imre13:06:14

Is it decided how clj-kondo would handle cases where there are multiple specifications are present from #{type-hint malli clj-kondo ...}?

imre13:06:50

It does sound like this would have its uses

borkdude13:06:40

@U08BJGV6E malli + clj-kondo just works because malli emits the clj-kondo configuration on disk which clj-kondo then uses. clj-kondo doesn't know anything about malli

imre13:06:54

Oh I see

Noah Bogart14:06:00

i'm struggling to find in the docs, my apologies if it's obvious: how do i tell clj-kondo that a given cljc file will only be used in clj and bb, and NOT cljs?

borkdude14:06:48

{:cljc {:features #{:clj :bb}}}

borkdude14:06:05

it will actually only use known features, so it will also skip bb unfortunately, this is still work in progress

Noah Bogart14:06:12

is that what this error message is about?

src/noahtheduke/splint/utils.cljc:0:0: error: Can't parse src/noahtheduke/splint/utils.cljc, No matching clause: :bb [:syntax]

borkdude14:06:37

probably

馃憤 2
borkdude14:06:12

this is on the top of my things to improve

borkdude14:06:22

since it will also be useful for clojuredart, etc

Noah Bogart14:06:54

yeah, for sure. no rush from me, this is an easy fix

lread14:06:47

yeah, this might be useful for cljdoc static analysis (wip) too, for, like you say clojuredart, clr, etc.