Can a defined transformer access the schema ? So given [:map [:key {:option :cool} keyword?]] Can a transformer access the [:key {:option :cool} keyword?]] data ?

@johan178 yes, the current transformer is of type schema opts => value => value, so:

[:map {:decode/string (fn [schema opts] 
                        (let [cool (:option (m/properties schema))]
                          (fn [value] …)))}]

the syntax will change before hitting first public to:

[:map {:decode/string {:compile (fn [schema opts] 
                                  (let [cool (:option (m/properties schema))]
                                    (fn [value] …)))}}]

@ikitommi Thanks for the quick PR review! Would you be open to me adding .nrepl-port and .dir-locals.el to gitignore? Alternatively if you want me to commit a .`dir-locals.el` it would make it so that new people contributing would automatically adhere to your style preferences

@rschmukler sure, go ahead, either way

:thumbsup:

.dir-locals.el is only relevant to cider users, so I wouldn't commit them. In general tooling/IDE config files shouldn't live in source repos 😛

.dir-locals.el is relevant to all emacs users

But I'm happy to not commit it - just could save PR time of people having to adjust their formatting to the project style

https://github.com/teknql/aave - First rendition of Aave!

agree on Esko for now, so let’s ignore the files.

Congratz on Aave!! I’ll add it to README as soon as the PRs are merged (just did the interceptor :compile, will merge it after yours @rschmukler).

Woo! Thanks! Love the momentum we've got going on!

@ikitommi What're your thoughts for potentially adding support for a dynamic variable for either full on malli options, or perhaps something like *registry-extensions* which is usually nil but is automatically merged into default-registry when set. I sometimes find myself having to thread malli options through things, or wrapping malli functions with my own namespace with a custom registry, etc. Since it's mostly for compile-time code anyway, the performance implications shouldn't matter much. Part of me feels like it might be too "magical" but the other part makes me feel like it could improve ergonomics

need to think about that.

@rschmukler do you have plan to fix the 142? (the is the x bug IMO + the formatting)

I think I already did no?

I force pushed updates an hour or two ago

Let me know if it needs anything. The x bug wasn’t caught by tests because map-of tests were disabled so I also fixed those

oh, the review panel just doesn’t show the updated. my bad. will merge.

Awesome!

could you check https://github.com/metosin/malli/pull/146 ?

Yep, will take a look now

Looks good! Sorry I missed some indents

np, off to weekend. cheers.