Fork me on GitHub
#cljs-dev
<
2018-08-12
>
Oliver George06:08:59

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.

bhauman15:08:26

@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.

Oliver George21:08:59

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

Oliver George21:08:38

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.

Oliver George21:08:16

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.

Oliver George21:08:46

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

Oliver George21:08:36

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.