Fork me on GitHub
#boot
<
2015-07-19
>
petrus11:07:50

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?

annapawlicka12:07:27

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

martinklepsch12:07:37

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

martinklepsch12:07:49

@annapawlicka: think of this as lein install

annapawlicka12:07:41

ah gotcha, thx!

martinklepsch13:07:18

@petrus: maybe closure constants could help with this?

meow14:07:47

@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

meow14:07:16

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

martinklepsch14:07:29

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

meow14:07:24

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

alandipert15:07:45

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

alandipert15:07:02

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

alandipert15:07:06

@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

alandipert15:07:28

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

petrus17:07:20

I like the cljs approach

petrus17:07:26

thanks, @alandipert.

robert-stuttaford17:07:05

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

alandipert17:07:41

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

meow17:07:03

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