This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-09
Channels
- # announcements (5)
- # aws (5)
- # babashka (7)
- # beginners (152)
- # cider (10)
- # clj-kondo (30)
- # clj-on-windows (1)
- # cljs-dev (14)
- # cljsrn (19)
- # clojure (94)
- # clojure-australia (4)
- # clojure-europe (43)
- # clojure-nl (2)
- # clojure-uk (11)
- # clojurescript (16)
- # clojureverse-ops (5)
- # code-reviews (7)
- # community-development (6)
- # core-async (29)
- # cursive (50)
- # datomic (22)
- # docker (10)
- # figwheel-main (3)
- # fulcro (4)
- # graalvm (1)
- # introduce-yourself (2)
- # kaocha (9)
- # lambdaisland (2)
- # lsp (19)
- # malli (37)
- # off-topic (50)
- # polylith (8)
- # portal (1)
- # reagent (10)
- # rum (1)
- # shadow-cljs (24)
- # spacemacs (14)
- # yada (2)
though experiment: • persist function schemas into edn/file (var->schema) • write a clj-kondo plugin/hook that looks from afile if a Var has a malli schema defined. If it has runs that validation (inputs & outputs) to it and reports. Static analysis with full malli :thinking_face: 🚀
I think you could have some kind of development runtime hook that writes clj-kondo type config as you go. But if I understand correctly malli already has this
one issue is that statically visible values are not the runtime values, so validating on those has different behavior
yes, malli.dev/start!
re-writes the the clj-kondo config on any change to the function registry
yes, that works with simple/demo cases. would need typedclojure to follow the types for real? and actual runtime to track the values for real?
I guess one could just add new keys to the clj-kondo config too? e.g. :malli/schema [:=> [:cat :int] :int]]
{:linters
{:type-mismatch
{:namespaces
{malli.demo
{plus
{:arities
{1 {:args [:int]
:ret :int
:malli/schema [:=> [:cat int?] pos-int?]}}}}}}}}
but when your plugin is called with the input types, it would have to do something similar to the clj-kondo "type" system right
it is converted already to clj-kondo type system. In top of that, using second round of malli-vqlidation, one could catch more, like integer min&max sizes, collection limits, closed maps, multis, sequences etc. The code would require access to:
1. function arguments
2. the :malli/schema
value (from linter config).
not sure if this is anyhow useful, but might be doable? At least emitting the malli-schema to the linter config would be a +1loc in malli.
in that case malli would have to be built into the clj-kondo or clojure-lsp binary, unless you run it on the JVM
what you could do, as it is now, is programmatically generate hooks for each var that has a malli spec
there you can have access to the arguments and do whatever you like, throw exceptions. The hooks already have access to the linter config
and then you could write some validations like malli but in user space, just as a proof of concept
or you can fork clj-kondo and add malli to the type system and explore until you reach some interesting conclusions
I'm also open to clj-kondo type system improvements, there are a few low hanging fruits perhaps
... also, if the config-file could be used as a.simple database, the tool could run Malli's check
once for each var (gen-test) and mark :malli/check
with the result (nil or error) - "function does not conform to it's schema, with arguments [0 -1], the result is -1, which is not a positive integer"
is it possible to enable generative testing (`{::m/function-checker mg/function-checker}`) for all function schemas during test runs without adding a (when (= :test (:env app)) ...)
to every schema manually?
there is an issue to allow setting default options. Before that, you could redefine the var where it's read / defined?
yeah, maybe i’ll try that
Question, say I want to try Malli but I don't have the fire power to rewrite all the specs...What would be the best "migration strategy" there? We instrument every function in dev mode and tests and we use specs for our domain model and http param validation at the moment. What I am worried about the former and the following - how can I instrument a function that has been partially covered with spec and partially with Malli?