I am working on a project to analyze a PR and check changes in schemas of functions (plumatic schema specific). I saw that clj-kondo, does check some schema information, but it drops from the output. Is there any reason to don't add this information to the output (probably using a proper option to include when needed)? If no, is something that I can contribute?
I made a PoC locally, the idea is to have something like that:
(clj-kondo.core/run! {:lint ["user.clj"]
:config {:analysis {:schemas true}}})
user.clj
(s/defschema User {:name s/Str :age s/Int})
(s/defn get-user :- User
"doc"
[id :- s/Uuid db]
nil)
(s/defn multi :- (s/maybe s/Int)
([x :- s/Int] x)
([x :- s/Int [a b] :- [s/Int] & more :- [User]] x))
output example
{:name get-user
:schema {:output "User"
:arities [{:inputs [{:arg "id" :schema "s/Uuid"} {:arg "db"}]}]}}
{:name multi
:schema {:output "(s/maybe s/Int)"
:arities [{:inputs [{:arg "x" :schema "s/Int"}]}
{:inputs [{:arg "x" :schema "s/Int"}
{:arg "[a b]" :schema "[s/Int]"}
{:arg "more" :rest true :schema "[User]"}]}]}}
Is that related to this issue? https://github.com/clj-kondo/clj-kondo/issues/1268
Yeah, I was checking this right now.. I forgot to check for open issues before (my bad)
From my understanding, you prefer to have this information more generic and inside :context right?
something like this:
;; {:analysis {:context [:schema.core]}}
{:name multi
:arglist-strs ["[x]" "[x [a b] & more]"]
:context {:schema.core {:output "(s/maybe s/Int)"
:inputs [[{:arg "x" :schema "s/Int"}]
[{:arg "x" :schema "s/Int"}
{:arg "[a b]" :schema "[s/Int]"}
{:arg "more" :rest true :schema "[User]"}]]}}}
I don't remember very well, it's been 6 years since that issue. Is this Nubank-specific since you and Eric are both interested in it?
I don't know about @ericdallo, if was related to Nubank or more clojure-lsp since is being a long time. But my interest is related to Nubank-specific, I am running some analysis on PRs to see if someone is doing a change that could be a potential breaking-change. We do that by running kondo analysis on both PR branch and target branch, then comparing. Now, I am evolving that to look at schema changes. Since we already use kondo for code analysis, will be good to have the schema information there. Otherwise, I will need to parse all code manually again to extract this information 😕
since schemas can be dynamic (constructed from pieces at runtime) and your proposal is to just include them as strings, what would you do with them?
My interest was and is support for schemas in clojure-lsp to use in features like docs and more, it's a long asked feature for clojure-lsp and yes Nubank is a big user of that, would be really nice to see that landing somehow
The PoC that I have locally working with the clj-kondo version that I shared is parsing the string, then resolve symbols with kondo's own usages and when a schema references another schema from the same lib (e.g. User), we read that def's source using the position kondo reports and substitute it.
I also have an experimental idea that eval a few pure fns over literals (`assoc`/`merge`/`set/union`...)
Anything still dynamic becomes an opaque form compared by equality: a change there is a warning, never "breaking". Is a restriction, but in our context is a small percentage of schemas, so right now is ok.
and this is specific to schema right? I haven't heard a lot from schema users in recent years, but I guess it's still widely used at nubank?
maybe you two can look at Arhur's POC together and decide if that's also what would be useful for clojure-lsp and then come back?
both work for clojure-lsp, I suggested one https://github.com/clj-kondo/clj-kondo/issues/1268#issuecomment-924444943
ok, well, looking forward to a PR then. Please test it well on your code bases :)
and preferably there won't be any performance cost to those not using the feature