This post will be a quick note since it's too tedious to go into the details. For the inpatient, you may clone the repo below and start exploring: https://github.com/minimal-xyz/minimal-shadow-cljs-webpack Here's how it worked. Normally for a compile...
Markdown supported · ⌘↵ to post
Just wanted to say that I think this is a good idea and would def use a mature and stable version of it. :)
I won't argue about shadow-cljs, although it's self description doesn't say much about what it does (provide some good defaults). I assume your goal is to use CLJS library in an application bundled for the browser using Webpack. CLJS compiler has an option to emit node.js compatible code using
:target :nodejsoption. You would presumably use this to bundle up your CLJS project as CommonJS module. With this, you can annotate your public functions like so(defn ^:export do-somthing [a b] (...))you could then use them in your JS code asmyns.foo.do-somthing(a, b)afterrequire()orimportyour module. So that's how you would use your module in production build. If you want live coding, I think figwheel is amazing in what it can do, far more than Webpack's HMR (eg. CIDER, Fireplace, ...). If you want to use live-code your CLJS library in your Webpack JS application, you can comment out therequire()orimportin your JS client code, and include Figwheel enabled JS file in an extra<script>tag. Hence you won't use Webpack's HMR for CLJS code, you will get faster reloads, and you will be able to eval code from your editor, in your running Webpack app in the browser, and you won't need additional dependency on shadow-cljs