Fork me on GitHub

anyone know why boot would crank a project up into clojure 1.8 even though i have a dependency on [org.clojure/clojure "1.9.0"]


i’m not sure I understand what this means


apparently you ave to specify in the global boot properties file. that seems strange

Garrett Hopper03:03:31

@vikeri I ended up only having to do a CloudFront invalidation for my index.html file which reference each split (or perhaps a single js bundle for you) with an included hash in the filename. I had to manually generate these hashes though. Interestingly the cljs compiler already allows for cache busting for source maps ( I wonder if it's a useful enough feature to add for actual code bundles.

Garrett Hopper03:03:09

@dpsutton See I have a file in each of my projects right next to build.boot

(It's essentially just the output of boot -V, so boot -V > would give you a default.) Boot needs the clojure version from the environment variable before it even boots up, because it can't parse the clojure version from the build file. The clojure version is really just there for other projects which may depend on this project. (Please someone, correct me if I'm wrong.)


ahh. ok. didn't realize it was a custom environment file for each project. thought build.boot handled it. thanks!

Garrett Hopper03:03:25

@lwhorton boot-cljs by default builds all .cljs.edn files on the classpath. They're typically in the resources folder specified by (set-env! :resource-paths #{"resources"}) (they could also technically be in the source directory). If a .cljs.edn file doesn't exists, one is generated which will compile everything. It can be a little tricky sometimes, because if :ids is supplied the name of a .cljs.edn file which doesn't exist, it won't throw an error; it will simply generate one with that name, if I remember correctly. It's probably best to create a main.cljs.edn file in your resource folder and supply adzerk.boot-cljs/cljs with :ids #{"main"}.

Garrett Hopper03:03:16

@dpsutton Yeah, it isn't very clear without reading through the wiki. There's a lot of good stuff in there, I highly recommend reading through applicable part of the wiki:, if you plan on using it extensively.


What’s the current state of figwheel + boot?


@borkdude there is figreload which works fine with figwheel 0.5.14 :)


No REPL integration at the moment though


Wasn’t there some effort in figwheel itself to make it less coupled with the lein task or something?


Yes there was, but there is still a fundamental problem which is that in boot REPL and reload and compiler run in different pods


So I don't know if we'll ever gonna have feature parity


What is the disadvantage of not having the REPL integration and using the other REPL?


The repl state is not synced with app


You can still use the reload approach no problem


Modifying sources and seeing the HUD + things reloading


What is the advantage of boot figreload over normal boot reload?


The figwheel HUD is better at visualizing things (the last time I have seen it)


Nothing else server side...they work the same


I actually reused Juho code for the reloading and just transform data to the figwheel Websocket messages


I am using expound for getting better error messages, but they end up in the console. Would be nice to get that in the HUD


Uhm, never tried that probably due to the fact that are printed to the out stream ...not sure...does it happen with both the "reload" tasks?


Oh this is just something that would be nice. I have no idea if figwheel does anything nice for this


Haven’t used figwheel in ages, which is a shame, because it seems to get some enhancements lately


How does tools.deps compare to boot in terms of programmability? I wonder.


@borkdude deps tools is a dep resolution thing, no pipelines, no programmability apart from the resolution library.


Sorry wrote pipelines twice :)


So like that word ah ah


This seems ok to me: No pipelining, but then again, I don’t need it that much I guess


Totally stamping on boot's thunder here but: - feel free to PR krei with unlimited dependencies until it does what you need - I'm trying really hard to figure out what krei should look like, pipelining doesn't directly make sense because of other things, if you have a compelling case for pipelining, let me know, or open an issue RFC.


I'm interested in dependencies, if not pipelining.


Yep but what I mean is that you need to roll your own build scripts and if the app is complex then boot can still be an option