Fork me on GitHub
Joshua Gelbard04:01:15

one character typo found, I think? looks like the vreset! in is meant to be a reset!, since instance-ref is an atom.

Joshua Gelbard04:01:30

I could make a PR 😛 (seems like overkill)

Joshua Gelbard04:01:08

; eval (current-form): (reload!)
; (err) Execution error (ClassCastException) at shadow.cljs.devtools.server/reload! (repl_fast.clj:526).
; (err) class clojure.lang.Atom cannot be cast to class clojure.lang.Volatile (clojure.lang.Atom and clojure.lang.Volatile are in unnamed module of loader 'app')


hmm right. it used to be a volatile but isn't used anywhere. so I guess nobody ever used it in 2 years or however long ago that change was


We want to call shadow.cljs.devtools.api/release to build our production asset, but we need to inject closure-defines into the config. is there are way to do this currently? are we holding it wrong/shouldn't have to do this? if not, would you accept a PR to either accept :closure-defines inside the opts or to accept the build-config instead of a build id as the first arg? (so then we can fetch the config via s.c.d.config/get-build , override the closure-defines and pass it to release). could also go via release*, but then you have to set up the env etc. and from my current POV this could be a useful feature. (this is not about injecting a define that differs between envs – think e.g. hosted client vs on-prem client, where we need to configure different backends)


its fine to call the release* function directly. just need to setup the runtime once. which is just (api/with-runtime ...) just like here


as Martin suggested config-merge is also an option. it can be passed in opts via {:config-merge [{:clojure-defines {' 1}}]}. note the extra vector though.

🙌 2

usually easier to just get the build config directly and modify it however you want


if you run via the runtime is already created, so you could skip the with-runtime