Fork me on GitHub
#malli
<
2022-05-29
>
ingesol11:05:22

Is it possible to make the code below work on the JVM, or is there some limitation in the implementation of CLJS function schemas that only makes them accessible in the JS runtime? My function schemas work and reload nicely in the browser, but in the code below the collect-cljs call always returns () . Additional info: All my function schemas are :malli/schema metadata.

(defn -main
  [& _]
  (-> (malli.clj-kondo/collect-cljs) 
      (malli.clj-kondo/linter-config) 
      (malli.clj-kondo/save!)))

ikitommi15:05:08

Good question. I have no idea! I believe @danvingo knows.

dvingo21:05:02

if you have a symbol in your functions schema like:

(defn minus
  {:malli/schema [:=> [:cat :int] [small-int]] }
  [x] (dec x))
small-int can only be resolved at runtime by a js vm. that's the fundamental limitation to why it won't work on a java vm

ingesol04:05:35

Thanks for clarifying, @danvingo. Also, big thanks for all your recent work on the CLJS tooling, it’s made a huge difference!

dvingo15:05:03

no problem. Ah that's great to hear! glad it's working for you - interested to hear if you have any feedback or things that could be improved, but if all is well that's great too 🙂

dvingo15:05:14

in case you didn't know there's https://github.com/metosin/malli/blob/384e31b325928a29f6bfdddae3a9f1241be4734b/src/malli/clj_kondo.cljc#L203 which is intended for use in a cljs repl - it's manual, you have to copy and paste to the kondo config. Are you trying to output the kondo config using a script (somewhat automated)? One thought I had is that for scripting support we could add a write function for node.js, the only annoying thing is that any browser APIs not available in node.js would probably break things, which would mean you'd have to change the structure of your code to put the function with schemas in one place. There's tradeoffs in all these approaches unfortunately

ingesol16:05:58

Yeah, that sounds a bit too much, I was thinking about node as well but probably not the route to go. My use case: I would like to keep the clj-kondo config in version control. The ideal would be a process that recompiles the config on every code change, so it would be obvious for the developer that the config is changed and needs to be pushed.

ingesol16:05:16

being able to print it to console and then copy into the file is not too bad, will probably be fine.

ingesol16:05:17

As for the general usability of CLJS: I’m using shadow-cljs. I followed the advice in the docs, and things seem to mostly work. I think I stumbled upon a file here and there that wasn’t being updated when schema changed, but it usually is fixed by a refresh.

ingesol16:05:21

Don’t have much detail on that here, as I’m not actively working on that code right now. But I will in a few weeks, will try to investigate properly then. But current state of things is perfectly fine for me!

dvingo13:05:16

I see, the use-case makes a lot of sense, I'm wondering if there is a way to achieve it as part of the build process in CI. The tricky part is you want the code to be evaluated in a browser, but you also want access to the filesystem. I was thinking about something like karma tests - running in a headless browser in node... Not sure if that would work.

dvingo15:06:08

Another idea to get this a bit more automated: add a dev-time only button to your app that sends the cljs kondo config to a specific endpoint which writes to the kondo config file - so it's just a button press

ingesol15:06:50

Yeah, that could work. Might be our preferred solution in the end 🙂

dvingo15:06:49

oh - or just do it in your reload hook! then no interaction needed

ingesol05:06:23

True, that’s what I’m doing right now, but of course just printing to console.

ingesol05:06:39

Question: I’m exclusively using keywords in schemas, never symbols. At least for now. Would I be able to “cheat” by telling the malli->cljs-kondo API that my cljs codebase is clj?

dvingo15:06:49

you could put them in cljc files and they'd be picked up when you collect clj schemas. Other than that, take a look at the source, the code is pretty tiny that collects the schemas, so you should be able to get it working (I think) with your own kondo wrapper. The library can't make those assumptions about what user schemas will have in them, but with those assumptions I don't think there's a reason it can't work