Fork me on GitHub
Lukas Domagala02:11:57

i’m having problems with the kondo cache, it seems running with :cache true and false takes the same amount of time and deleting using a different :cache-dir doesn’t change the time either


Can you be more specific about what the actual problem is you’re experiencing @domagala.lukas ? The cache is used to get information about other namespaces while linting in your editor. It’s not a performance thing. But you can skip linting already linter deps using the dash dash dependencies flag.

Lukas Domagala09:11:17

@U04V15CAJ i’m running it through

clj-kondo/run! {:cache-dir ".kondo/.cache"
                                       :parallel true
                                       :cache true
                                       :lint files
                                       :config {:output {:analysis true}}})
i need the analysis, but dont really care aboute the linting part since its in process with the source anyway + i’ve got lsp running with a second analysis. i was hoping i could share the kondo cache that lsp’s running version produces to make my in process one faster


@domagala.lukas What kind of files are you linting. Just normal source files or .jar files?

Lukas Domagala10:11:58

@U04V15CAJ both. i’m basically using kondo as a dependency analyzer for function calls to get a deep call graph

Lukas Domagala10:11:18

if you’re interested in the exact usecase: currently working on a feature that lets you make a function call that automatically instruments the call graph, but only that and then removes the instrumentation right after the call. i don’t want to search for the dependencies myself though, since you already did the work for me :)


@domagala.lukas clj-kondo skips dependencies it already linted with :dependencies true . But it doesn't return analysis for those dependencies it skipped. You need to implement your own caching in this case. Just save the analysis information of previously analyzed files somewhere and then combine it with the new analysis.


This is what LSP itself is also doing.


I think you don't even need to lint all the jars every time if you do that, just lint the source the user changed.

Lukas Domagala11:11:29

yeah that’s what lsp is doing and saving it as a datalevin file, I just didn’t want datalevin as a dependency. was hoping kondo’s cache did the same thing. but yeah you are right, i’ll just do it the same way lsp does it and save it as plain edn. is there a way to run the analysis without running the linting part, since i don’t use that info anyway? or wouldn’t that change much about the run time anyway? thanks for the help btw


it wouldn't change much


but you can turn it off by replacing all linters with level off:

:config {:linters ^:replace {}}

👍 1

When I look at the transit-json data, the exported symbols are there but they lack the correct function arities and the documentation.


Less important they also lack the correct links to the actual source files. For example, from the repl, this is the metadata of>:

user> (require '[tech.v3.datatype :as dtype])
user> (meta #'tech.v3.datatype/->reader)
{:line 146,
 :column 1,
 :file "tech/v3/datatype/base.clj",
 :name ->reader,
 :ns #namespace[tech.v3.datatype],
 "If this object has a read-only or read-write conversion to a buffer\n  object return the buffer object.  Else throw an exception.",
 :arglists ([item] [item read-datatype])}


The file, line, column inforrmation allows emacs/cider based pathways to find the correct true definition.


This gets into the heart of something I was curious about - when does clj-kondo actually load a required file and can I get to the actual namespace definitions in another source code file, not in some definition under .clj-kondo/...


Clearly it does both.