Fork me on GitHub

the plumatic syntax is merged in master, also better dev-tooling for CLJS (thanks to @danvingo!). Looking forward to test reports, will release soon/after.

🎉 7
Noah Bogart13:01:40

That’s so exciting!


I’m interested in using malli with clj-kondo for static type checking. We already have clj-kondo in our project, and I saw in the malli readme on how to generate configs. Wondering if there are any decent examples that would demonstrate how to organize this for a large production code base?

Ben Sless17:01:03

Static type checking in Clojure is a bit limited without type inference, which malli and kondo don't do. You'll have to specify everything you want checked. A sane middle ground is having a "schema" namespace where you specify the schema of data coming in or out of your code base, then validate at the edges of the system.


clj-kondo does have some type inference

Ben Sless18:01:54

(some type-inference? clj-kondo) ;; => true How much type inference does it do, exactly?

😂 1

it has return type inference and locals inference for example


$ clj-kondo --lint - <<< '(let [x :foo] (inc x))'
<stdin>:1:20: error: Expected: number, received: keyword.

awesome 1

$ clj-kondo --lint - <<< '(let [x (inc 2)] (assoc x :foo :bar))'
<stdin>:1:25: error: Expected: associative collection or nil, received: number.

awesome 1
Ben Sless18:01:45

Do associative collections carry around type information about their keys?


there is some of this, don't remember exactly how much, but probably not a lot


there is one open issue by @U055NJ5CC about this, that I haven't gotten around to yet


we already use plumatic.schema for data validation at the edges. I’m primarily talking about this: I can see how to define the function spec right after with m/=> .


What I’m wondering is if there’s a best practice for emitting all of the configs for a project after defining the specs in each ns?


And further than that, would this buy me anything when it comes to associative collections?


But even just using it for arg types and return types, it’s still a step up imo


@U774Z4VJA you get things for free and it might improve over time if you complain enough in the #clj-kondo channel :)


associative collections: if you specify a required key as input to a function and you pass a map literal, then clj-kondo will be able to see it

❤️ 1

but the inference on associative collection needs more love


ha, ya. Maybe if work stay calm enough, I may even be able to contribute here and there 😉

👍 1

Any tips on emitting config for a whole project?


for this question I defer to the malli authors!


ofc thanks


tl;dr of above thread. One unanswered question: Any tips on emitting clj-kondo config for a whole project?


There is no guide for that and as there are 3+ ways to declare the schemas for functions, no best practices yet I think. I put the schemas next to the functions (my favourite is the plumatic-syntax, so inlined) and have the ! in the user / dev namespace, so you can do that easily. It instruments all the functions from all loaded namespaces, so should work ok.


if not, please report 🙂 planning to mallify a large codebase, can comment after that how it works / doesn’t.


if you are doing that already, user experience report post & feedback most welcome


Many thanks for the response! Will ! also emit the clj-kondo config @U055NJ5CC?


That is 🔥


I also like the plumatic syntax so very cool that was just added