Clojurians Log v2
boot
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?
@michael.heuberger 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?
I don't know about libraries, but it's what we're doing and it seems to work just fine
Do you use a new boot file in each subproject?
Yeah
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
thanks
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
that’s one of my proposals. We’ll see if the team goes for it 🙂