Fork me on GitHub
#boot
<
2018-05-22
>
michael.heuberger00:05:54

hello folks, how can i tell in a deftask of build.boot to compile the js assets into a single file instead?

michael.heuberger00:05:17

(task-options! cljs ... <-- what parameters to pick here?

martinklepsch09:05:40

You mean :optimizations :advanced?

michael.heuberger21:05:14

Tried that, still comes in fragmented js files

michael.heuberger22:05:41

(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)))

michael.heuberger22:05:02

that’s the code. running $ boot prod still puts fragmented js files in the target folder. only want one js file. any clues?

martinklepsch06:05:05

@U0HSJK7GQ the cljs compiler creates intermediary files, you only need the one you specified as :output-to

michael.heuberger21:05:52

ah - that was the confusing part. wish the intermediary files were somewhere else, in a temp directory for less confusion.

arohner14:05:16

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?

danm14:05:20

I don't know about libraries, but it's what we're doing and it seems to work just fine

arohner14:05:53

Do you use a new boot file in each subproject?

arohner14:05:59

Can you call one boot task from another? like if I wanted to run test in all subprojects, how does that work?

arohner14:05:15

(apologies, I haven’t found docs on this. If there are some, please point me at them!)

danm14:05:58

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

danm14:05:08

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

arohner15:05:32

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

arohner15:05:03

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

danm15:05:23

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

danm15:05:20

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

flyboarder16:05:17

@arohner there is multi-boot

flyboarder16:05:35

But I would recommend just running multiple terminal windows which is what I do

flyboarder16:05:07

and then using boot :checkouts within my microservices

arohner16:05:52

@flyboarder link? Search is failing me

flyboarder16:05:00

it’s out of date but the wiring should still work

flyboarder16:05:31

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

arohner17:05:44

I’ve seen that at previous jobs, and really hated it. I find it tedious, and error prone when you forget to bump versions

😅 8
alandipert17:05:17

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?

alandipert17:05:24

i guess i can think of at least one, different services need conflicting deps

arohner19:05:17

that’s one of my proposals. We’ll see if the team goes for it 🙂