Clojurians Log v2

Thanks for the update! Looks good!

I mean codegen. I want to describe malli schema and then have all the goodies (pull vectors, pathom resolvers, etc) generated. I may end up doing it myself, just asking if you have seen anything like this already.

Let's not forget https://github.com/kwrooijen/gungnir

I'm just trying malli for the first time today, and it looks pretty great already

one thing I didn't quite understand though, if I annotate a function with (m/=> ... is there a way to actually force that check at runtime to make it fail when the schema doesn't match? I only see that related with generating a clj-kondo config, which is great but I thought that run-time assertions would be also there, even if disabled by default maybe

https://github.com/metosin/malli/issues/349 but @setzer22 has a working implementation https://github.com/setzer22/malli-instrument

Yes, I've been using my implementation for a couple of weeks now 👍 The base features are working, but sometimes malli has trouble generating human readable descriptions of errors

if you give it a try, please report any issues!

ah nice, yeah no rush was just wondering if I missed something from the docs

@setzer22 yes, there is an open PR about robust humanized errors. Few combinations that don’t work, but the idea to fix it seems legit.

@ikitommi Good to know!

another thing I noticed is that there isn't a way to just throw an exception if something fails to validate. I ended up with something like

(let [my-map ...
       errors (m/explain schema my-map)]
  (if (nil? errors) my-map (throw (ex-info "validation failed" errors)))

We should have an assert...

There wasn't even an issue so I made one https://github.com/metosin/malli/issues/420

Hmm hard to make an efficient assert that makes the validator and explainer behind the scenes. Especially Cljs would be tricky.

mm maybe you don't always need the explainer

would be nice I guess but not sure it needs to be the default

Dropping the explainer does not make it any easier.

Thanks for creating the issue! it must have slipped my mind. Do you mean caching a validator at the assert's compile time? I would be worried about the validator then going out of sync when you redefine the schema during dev time

Maybe the *assert* dynamic var could have 3 levels: • runtime validate (slowest but correct) • compile-time validator (more efficient, use if schemas are fixed) • compiles to nil