This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-30
Channels
- # arachne (2)
- # beginners (8)
- # boot (19)
- # chestnut (2)
- # cider (1)
- # clara (1)
- # cljs-dev (31)
- # cljsrn (82)
- # clojure (163)
- # clojure-dusseldorf (7)
- # clojure-greece (1)
- # clojure-italy (4)
- # clojure-norway (3)
- # clojure-russia (24)
- # clojure-sg (5)
- # clojure-spec (6)
- # clojure-uk (42)
- # clojurescript (239)
- # core-async (4)
- # cursive (10)
- # data-science (18)
- # datascript (1)
- # datomic (110)
- # emacs (16)
- # euroclojure (1)
- # events (1)
- # figwheel (1)
- # hoplon (22)
- # keechma (2)
- # klipse (5)
- # lein-figwheel (3)
- # leiningen (7)
- # luminus (27)
- # melbourne (2)
- # mount (5)
- # nyc (7)
- # off-topic (35)
- # om (20)
- # onyx (49)
- # pedestal (41)
- # re-frame (31)
- # reagent (18)
- # remote-jobs (9)
- # ring (4)
- # ring-swagger (1)
- # spacemacs (6)
- # specter (6)
- # uncomplicate (3)
- # unrepl (9)
- # untangled (54)
- # yada (11)
Hello folks. I'm trying to run CLJS tests that require a browser env. I tried boot-cljs-test
but got some error doo is undefined
when running under firefox. I feel like Doo and Karma are a bit overwhelming, and both doo
and boot-cljs-test
seem outdated with regard to Karma versions. Or not ? Am I wrong ? How do you do ?
Wondering how other boot folks produce something similar to the env/dev/config.edn
, env/prod/config.edn
approach with lein + profiles
@pandeiro I don't understand the question. If you're using uberjars, lein profiles don't apply for prod, no?
generally though, I'd pass in the config file to my "system" as an option. Then -main
will use the prod one, and (dev)
will pass the "env/dev/config.edn"
@dominicm Thanks yeah that makes sense; what I meant was yes the :dev
profile lein has, and then in production maybe a deployment tool knows how to find the prod
version and put it on the classpath or in a determined location
@pandeiro if you want my slightly biased advice. I would advise using Aero & having only one config file 🙂
pandeiro: cprop is cool. It takes a merging approach, which can sometimes be unexpected, especially as everything in the config can be overriden by env variables. We've found (at least for the kinds of projects we've worked on!) that there's usually a handful of environment variables you need to actually get from the environment. In aero you'd do something like this in your config file:
{:port #long #env PORT}
You can do a fallback with #or
:
{:port #long #or [#env PORT, "1000"]
You communicate something different in each case:
1. This variable always comes from the environment
2. This variable sometimes comes from the environment
The explicitness is very useful when debugging.I think we may have a requirement for this project on using system properties for some config
You might find Aero a little cumbersome if you need to deploy into an environment where someone will arbitrarily want to override everything via an environment variable though. We work in environments where we know exactly what has to come from the environment.
system properties, hmm, we should support that. If we don't, the PR should be really simple.
This is great in that it has now become clear that I don't know exactly what the requirements are for the config piece 🙂
https://github.com/juxt/aero/blob/master/src/aero/core.cljc#L52-L55 ^^ implementation for reading java system properties, if this is what you meant 🙂
Looking through the cprop source, it looks like the merging could easily be: 1) part of aero (though anti-philosophy really) 2) merged after calling out to aero It's one or two functions deep to pinch it out by the looks of it 🙂
Does anyone one know whats up with "user/clojuredocs" in boot repl? the clojuredocs function just throws an error about not being able to find a clojuredocs client. Do I need to do something to set it up?