Fork me on GitHub
#clj-kondo
<
2019-12-05
>
dominicm20:12:36

It doesn't look possible to analyse a string from the kondo api, is that correct?

borkdude20:12:40

@dominicm you mean string instead of file?

borkdude20:12:09

you can do so with (with-in-str "<your-code"> (clj-kondo/run! {:lint "-"}))

dominicm20:12:59

I've never seen with-in-str before, neat.

borkdude21:12:27

@dominicm it's very handy for testing command line applications

dominicm21:12:16

I just hooked up the analysis to my code formatter. We've got some very cool things going on here... I'm able to accurately match defn.

dominicm21:12:21

Well, accurately as kondo... :)

dominicm21:12:55

So many evil awesome things to do!

dominicm21:12:26

Interesting, kondo doesn't detect (ns) as a var usage, should it?

dominicm21:12:20

(with-in-str "(ns foo)"
    (:analysis
      (kondo/run!
        {:lint ["-"]
         :config {:output {:analysis true}}})))
;; =>
{:namespace-definitions [{:filename "<stdin>", :row 1, :col 1, :name foo}],          
 :namespace-usages [],                                                               
 :var-definitions [],                                                                
 :var-usages []}         

borkdude21:12:02

it reports it as a namespace definition

borkdude21:12:04

the ns macro is treated as a special case I guess

dominicm22:12:41

Hmm. Maybe I can special case detection then...

borkdude22:12:21

I don't object to adding it to the var-usages though

dominicm22:12:37

Okay. May take a look :)

sogaiu22:12:17

will that lead to a removal from where it is already?

dominicm22:12:45

I wouldn't think so. I think both are useful.

sogaiu22:12:02

tnx -- i just have code that depends on the current structure 🙂

borkdude22:12:48

the call might have some more detail to it, like the amount of arguments (which is pretty useless information for the ns macro probably)

borkdude22:12:11

and the namespace it was called from, but maybe that hints at the reason why it wasn't there in the first place

borkdude22:12:25

because that place where it's called from is a bit of a grey area

borkdude22:12:58

so maybe it's fine as it is

sogaiu22:12:12

thanks for the clarification

dominicm22:12:03

It's useful to me for identifying what it is. Not some other ns, the one and true ns.

borkdude22:12:47

But are you interested in more than the location where ns was used?

dominicm22:12:16

Sorta. Kinda. I look at the arguments, like :require and manipulate them.

borkdude22:12:39

We could maybe add that info to :namespace-definitions

dominicm07:12:03

Then I have to look them up in a different place for ns.

borkdude07:12:05

But using :require in ns is not a normal function call anyway ?

dominicm07:12:11

That's fine contextually :) all I need to know is whether the symbol is clojure.core/ns or not

dominicm07:12:57

Currently I do that by cross referencing the location with the var usage data

borkdude07:12:40

It is also reported there ?

borkdude07:12:51

Sorry, not near a kbd, I’ll check on this later

dominicm07:12:33

No, that's what I reported yesterday...? I can derive the require once I'm inside ns, because that is contextual information

borkdude08:12:50

Ah, I see. Like we discussed you can fall back on the location in namespace-definitions for now but feel free to add it. I think the ns form is called from the same namespace the ns form is called in conceptually

dominicm08:12:29

Yeah :) I will.