Fork me on GitHub
#clj-kondo
<
2023-01-01
>
millettjon20:01:17

The https://www.unison-lang.org/ language reminded me of the old https://github.com/Datomic/codeq project. I am wondering if there is any interest in having clj-kondo work off a codeq style data store maybe backed by https://github.com/replikativ/datahike or https://github.com/threatgrid/asami.

borkdude08:01:24

The clj-kondo https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md can be stored in such a data store. In fact clojure-lsp has been doing this in datalevin for a while, but now it's using transit (like clj-kondo itself). Once you know the queries you're going to do you can optimize for that in your storage format. Clj-kondo tries to conservative in the amount of dependencies involved, so it's not using datahike or asami, just transit files.

millettjon14:01:03

Thanks. I didn't know clojure-lsp was using datalevin. It seems like a global, immutable, semantic, content addressable code store would benefit every level of the tool chain. I am wondering what are the possible incremental steps to enable it in the various tools. I totally get keeping clj-kondo lightweight with minimal deps. Maybe there is a setup where a standalone code store is available, and tooling could optionally hook into it to gain additional super powers?

jeroenvandijk08:01:28

@U071T1PT6 I believe you are right about the content addressable code store. I think clojure-lsp and clj-kondo and others are “small” incremental steps towards this (in my opinion). Recently someone coined a related initiative with #C03FF6W62A3 Not sure where this is going, but you might find some more ideas there. I also thought of https://clojurians.slack.com/archives/C03FF6W62A3/p1653908127822239?thread_ts=1653905543.461139&amp;cid=C03FF6W62A3

millettjon14:01:05

@U0FT7SRLP Definitely relevant. Thanks for the references.