Fork me on GitHub
#malli
<
2022-01-09
>
ikitommi10:01:55

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!

metame17:01:01

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.

borkdude18:01:57

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
borkdude18:01:32

it has return type inference and locals inference for example

borkdude18:01:59

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

awesome 1
borkdude18:01:37

$ 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?

borkdude18:01:30

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

borkdude18:01:53

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

metame19:01:56

we already use plumatic.schema for data validation at the edges. I’m primarily talking about this: https://github.com/metosin/malli#clj-kondo I can see how to define the function spec right after with m/=> .

metame19:01:38

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?

metame19:01:09

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

metame19:01:09

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

borkdude19:01:37

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

borkdude19:01:25

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
borkdude19:01:32

but the inference on associative collection needs more love

metame19:01:36

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

👍 1
metame19:01:56

Any tips on emitting config for a whole project?

borkdude19:01:24

for this question I defer to the malli authors!

metame19:01:35

ofc thanks

metame19:01:10

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

ikitommi14:01:34

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.

ikitommi14:01:57

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

ikitommi14:01:18

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

metame14:01:20

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

metame14:01:11

That is 🔥

metame14:01:12

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