Fork me on GitHub
#malli
<
2021-08-09
>
ikitommi10:08:27

oh, it's the function values, need to short-circuit on them. Should be easy to fix.

ikitommi10:08:44

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: 🚀 parrot

Ben Sless10:08:00

separating type and code for functions seems like a footgun waiting to go off

☝️ 2
Ben Sless10:08:55

someone will change one and not the other

borkdude10:08:33

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

borkdude10:08:30

one issue is that statically visible values are not the runtime values, so validating on those has different behavior

ikitommi10:08:37

yes, malli.dev/start! re-writes the the clj-kondo config on any change to the function registry

ikitommi10:08:51

could emit the new var->malli-schema file too at the same time.

ikitommi10:08:03

(and malli.dev/stop! removes the file(s))

ikitommi10:08:02

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?

ikitommi10:08:32

I guess one could just add new keys to the clj-kondo config too? e.g. :malli/schema [:=> [:cat :int] :int]]

ikitommi10:08:11

would be just one config file then, always up-to-date.

borkdude10:08:49

you mean type aliases?

ikitommi10:08:53

{:linters 
	{:type-mismatch 
		{:namespaces 
			{malli.demo 
				{plus 
					{:arities 
						{1 {:args [:int]
				            :ret :int
				            :malli/schema [:=> [:cat int?] pos-int?]}}}}}}}}

ikitommi10:08:28

… for the plugin to read from.

borkdude10:08:56

but when your plugin is called with the input types, it would have to do something similar to the clj-kondo "type" system right

borkdude10:08:06

so why not convert the schema to the clj-kondo type system immediately

ikitommi11:08:28

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).

borkdude11:08:39

and you would need to invoke malli itself as well right?

ikitommi11:08:40

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.

borkdude11:08:12

in that case malli would have to be built into the clj-kondo or clojure-lsp binary, unless you run it on the JVM

borkdude11:08:19

what you could do, as it is now, is programmatically generate hooks for each var that has a malli spec

borkdude11:08:45

there you can have access to the arguments and do whatever you like, throw exceptions. The hooks already have access to the linter config

👍 4
borkdude11:08:04

and then you could write some validations like malli but in user space, just as a proof of concept

borkdude11:08:33

or you can fork clj-kondo and add malli to the type system and explore until you reach some interesting conclusions

borkdude11:08:22

I'm also open to clj-kondo type system improvements, there are a few low hanging fruits perhaps

👍 2
ikitommi15:08:18

... 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"

Noah Bogart15:08:50

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?

ikitommi16:08:16

there is an issue to allow setting default options. Before that, you could redefine the var where it's read / defined?

ikitommi16:08:31

dirty, but works

Noah Bogart16:08:37

yeah, maybe i’ll try that

ikitommi16:08:42

And please write an issue

👍 2
richiardiandrea15:08:06

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?

ikitommi16:08:08

create a spec->malli converter, PR that and enjoy the ride? :face_with_cowboy_hat:

ikitommi16:08:05

Not sure if the intstrumentatons stack, could just work?