Devops question: Our cljs frontend needs to know the API endpoint of our backend, which depends on the build env. Since we're using CircleCI for CI and deployment and recently switched to boot for building our cljs frontend, what is the best way to "configure" the build artifact during a production build so that it knows which endpoint to talk to? In the past we've done this by outputting a settings.js file that writes JS config variables to js/window, e.g. window.my-setting = "some setting"; and loading that JS file before our app, but it feels like it would be cleaner if this setting was part of the advanced compiled build. Is there some aspect of boot I'm not aware of that can do this?

@martinklepsch: do you have instructions on how to build boot for local development? I’ve added qualifier check to the clojure version check and would like to test it.

If there's a call to bootlaces! in the build.boot you can just run boot build-jar

@annapawlicka: think of this as lein install

ah gotcha, thx!

@petrus: maybe closure constants could help with this?

@petrus: https://github.com/clojure/clojurescript/wiki/Compiler-Options#closure-defines

@martinklepsch: I think that only works on variables in the Google Closure namespace, such as:

goog.DEBUG
  goog.LOCALE
  goog.TRUSTED_SITE
  goog.STRICT_MODE_COMPATIBLE
  goog.DISALLOW_TEST_ONLY_CODE
  goog.ENABLE_CHROME_APP_SAFE_SCRIPT_LOADING

So I'm not sure how useful those would be to @petrus - it sounds like he needs something else

@petrus: you may want to use https://github.com/adzerk-oss/boot-template

I thought you could define constants like these on your own as well. After all it's just JavaScript right?

You might be able to, I'm just not sure it would be wise to do so.

@petrus: one way is with a clj macro used in your cljs code, such as (defmacro target-env [] (System/getenv "TARGET_ENV"))

@petrus: that lets you embed a value in compiled cljs from the build environment

@petrus: an alternative is a task that generates a snippet of .cljs that goes in the fileset at build time, that contains some build-time constant

(similar to your settings.js approach, which is also feasible)

I like the cljs approach

thanks, @alandipert.

@petrus, you could simply pre-process a .cljs file with good old text replacements prior to cljs compile

doh, scrolling

oh yeah, that's great idea! there's even https://github.com/adzerk-oss/boot-template

you could pipe the cljs through, https://github.com/adzerk-oss/boot-template/blob/master/src/adzerk/boot_template.clj#L17-L27

@alandipert: hmm, I wonder who recommended that earlier... 😉