This page is not created by, affiliated with, or supported by Slack Technologies, Inc.


I see that cljs.main merges options left to right. That means the :clojure-defines in one edn file will get replaced by a second one in something like

clj -A:dev -m cljs.main -co ios-simple.cljs.edn -co prod.cljs.edn --compile
Would a patch which merged entries in the :closure-defines key be considered? That would avoids the need to keep all possible permutations of build targets and publishing/environment profiles by allowing clojure-defines entries to be accumulated across edn files.


@olivergeorge Its a slippery slope going from the simple semantics of merge to fuzzy merge, what if your intention is to override :closure-defines entirely? This is what lead lein to have metadata to determine what merge means for any given key. Which just gets crazy semantically. Better to have a simple merge and understand it, you can define the args you want precisely.


Fair call. I'll make the best case I can.


Firstly, :clojure-defines are used for two separate concerns: feature toggles and deployment settings. By feature toggles I mean "turn X on/off" and by deployment settings I mean "api url is X, analytics id is Y". It's likely that non-trivial applications will use both cases and want to mix & match them when deploying.


Secondly, I think merging the sub-map is true to a logical notion of merge... just not the clojure.core/merge. I don't think there's anything else in compilure options where this sense of merge is going to be surprising but that would be an argument against it.


Alternatives for me are a build script. Just seems like we're close to not pushing people to that.


And I acknowledge my bias. This change combines simple & easy for me.... but perhaps other use cases could suffer. If that's the case it's a bad idea.