This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-29
Channels
- # announcements (6)
- # babashka-sci-dev (15)
- # beginners (46)
- # calva (1)
- # clj-kondo (1)
- # clojure-australia (2)
- # clojure-europe (10)
- # clojure-uk (4)
- # clojured (3)
- # clojurescript (16)
- # fulcro (6)
- # helix (1)
- # hyperfiddle (8)
- # instaparse (28)
- # joyride (33)
- # malli (17)
- # off-topic (13)
- # pedestal (3)
- # portal (5)
- # react (1)
- # sci (1)
- # sql (6)
- # vim (1)
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!)))
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 vmThanks for clarifying, @danvingo. Also, big thanks for all your recent work on the CLJS tooling, it’s made a huge difference!
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 🙂
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
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.
being able to print it to console and then copy into the file is not too bad, will probably be fine.
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.
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!
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.
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
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?
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