This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-26
Channels
- # architecture (2)
- # beginners (310)
- # boot (34)
- # cider (50)
- # cljs-dev (82)
- # cljsrn (1)
- # clojure (125)
- # clojure-dusseldorf (1)
- # clojure-hamburg (1)
- # clojure-italy (47)
- # clojure-russia (21)
- # clojure-spec (38)
- # clojure-uk (36)
- # clojurescript (200)
- # community-development (21)
- # cursive (10)
- # datomic (15)
- # duct (58)
- # emacs (20)
- # fulcro (10)
- # funcool (1)
- # graphql (2)
- # hoplon (6)
- # jobs (1)
- # lumo (12)
- # mount (20)
- # off-topic (14)
- # om (5)
- # portkey (43)
- # protorepl (2)
- # re-frame (31)
- # reagent (36)
- # ring (17)
- # ring-swagger (6)
- # shadow-cljs (50)
- # spacemacs (9)
- # sql (5)
- # tools-deps (28)
- # uncomplicate (4)
- # unrepl (5)
- # vim (2)
- # yada (2)
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"]
apparently you ave to specify in the global boot properties file. that seems strange
@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 (https://clojurescript.org/reference/compiler-options#source-map-timestamp). I wonder if it's a useful enough feature to add for actual code bundles.
@dpsutton See https://github.com/boot-clj/boot/wiki/Configuring-Boot
I have a boot.properties
file in each of my projects right next to build.boot
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.9.0
BOOT_VERSION=2.7.2
(It's essentially just the output of boot -V
, so boot -V > boot.properties
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!
@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"}
.
@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: https://github.com/boot-clj/boot/wiki, if you plan on using it extensively.
@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
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
@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: https://github.com/juxt/edge/tree/master/app 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.
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