This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-22
Channels
- # architecture (1)
- # aws (3)
- # beginners (78)
- # boot (33)
- # cider (49)
- # cljs-dev (3)
- # clojure (82)
- # clojure-berlin (2)
- # clojure-dusseldorf (14)
- # clojure-gamedev (75)
- # clojure-italy (15)
- # clojure-nl (2)
- # clojure-poland (9)
- # clojure-russia (1)
- # clojure-spec (11)
- # clojure-uk (91)
- # clojurescript (17)
- # core-async (2)
- # cursive (1)
- # data-science (3)
- # datascript (34)
- # datomic (13)
- # docs (2)
- # duct (32)
- # emacs (8)
- # fulcro (95)
- # instaparse (17)
- # jobs (2)
- # jobs-discuss (1)
- # jobs-rus (4)
- # leiningen (1)
- # luminus (1)
- # lumo (4)
- # mount (1)
- # nrepl (1)
- # off-topic (98)
- # onyx (13)
- # portkey (12)
- # re-frame (10)
- # reagent (11)
- # remote-jobs (4)
- # rum (3)
- # shadow-cljs (34)
- # specter (7)
- # sql (1)
- # tools-deps (8)
hello folks, how can i tell in a deftask of build.boot to compile the js assets into a single file instead?
(task-options! cljs ...
<-- what parameters to pick here?
You mean :optimizations :advanced
?
Tried that, still comes in fragmented js files
(deftask build
[]
(comp
(cljs)
(target)))
(deftask production
[]
(boot.util/info (str "Building for production ..."))
(task-options! cljs {:optimizations :advanced
:compiler-options {:compiler-stats true
:closure-defines {"goog.DEBUG" false}}})
identity)
(deftask prod
"Simple alias to build production artifacts"
[]
(comp (production)
(build)))
that’s the code. running $ boot prod
still puts fragmented js files in the target folder. only want one js file. any clues?
@U0HSJK7GQ the cljs compiler creates intermediary files, you only need the one you specified as :output-to
ah - that was the confusing part. wish the intermediary files were somewhere else, in a temp directory for less confusion.
Are there any libraries for using boot in a monorepo? (multiple subprojects in the same github repo, with potential source dependencies between them). Do they work well?
Can you call one boot task from another? like if I wanted to run test
in all subprojects, how does that work?
(apologies, I haven’t found docs on this. If there are some, please point me at them!)
We're possibly a different pattern. We have microservices and libraries, so although we might have multiple microservices depending on a lib, we generally don't want to build everything as one big project. We integration test the libs locally using boot build install
and referencing them in the build.boot
for the microservice they're being altered for, then push them to our repo before we build the microservice out to live
We do have a Jenkins job which runs the unit tests for every project in the repo, which it just does via a shell find
looking for build.boot
files, and triggering an exec of boot test
in each directory one is found in
Ah. So I have a git repo with multiple microservices, and several shared libs. We want to be able to e.g. modify a shared lib, then test it, build the service that depends on it, and test the service, ideally without a PR + deploy in the middle
I think I can manage it if I could find an API to load the bootfile from a subproject and call tasks in it, maybe from a separate pod
Yeah, similar to us. But our pattern would be
1) Edit the lib (including ensuring unit tests pass)
2) Run boot build install
to install the new version of the lib locally (we actually use semver
to ensure we build a -SNAPSHOT
version for this)
3) Edit build.boot
of the microservice to ref the snapshot of the lib. Work on that until it also passes unit tests
4) Push new version of lib to repo (without -SNAPSHOT
tag)
5) Remove ref to -SNAPSHOT
tag from microservice build.boot
6) Push new version of microservice
If we really needed to test the lib functionality with more than just unit tests, in line with other microservices or with interaction with external systems like dynamodb, we'd build the microservice uberjar locally with the -SNAPSHOT
version of the lib and then push that up to the component running the microservice in our INT environment
@arohner there is multi-boot
But I would recommend just running multiple terminal windows which is what I do
and then using boot :checkouts
within my microservices
@flyboarder link? Search is failing me
one sec
it’s out of date but the wiring should still work
I would think tho that building SNAPSHOT
versions of your libraries and then using the built in mechanism via :checkouts
would be a faster solution
I’ve seen that at previous jobs, and really hated it. I find it tedious, and error prone when you forget to bump versions
is there a reason not to keep all the code in the same repo, and produce the same jar, but have different entrypoints, like perhaps different arguments or main classes depending on service?
i guess i can think of at least one, different services need conflicting deps