This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (19)
- # announcements (1)
- # beginners (14)
- # boot (244)
- # cider (2)
- # clojure (23)
- # clojure-dev (23)
- # clojure-poland (55)
- # clojure-russia (118)
- # clojure-uk (4)
- # clojurescript (143)
- # core-async (31)
- # core-logic (1)
- # cursive (30)
- # datascript (2)
- # datomic (3)
- # emacs (7)
- # hoplon (40)
- # ldnclj (8)
- # off-topic (2)
- # om (64)
- # reagent (10)
- # ring (1)
- # yada (71)
I'm still a bit confused as to when resources or assets are copied into the target directory
clojure (deftask dev "Simple alias to run application in development mode"  (set-env! :target-path "target") (comp (serve :dir "target/dev") (watch) (speak) ))
clojure (comp (serve :dir "target/dev") (sass :sass-file "app.scss" :output-dir "." :line-numbers true :source-maps true) (watch) (speak) )
what's the idiomatic way of telling boot to copy assets over to the target directory? perhaps there's a side-effect of the way the sass
task is working
[mathias/boot-sassc "0.1.5" :scope "test"]
I think the best reference is this: https://github.com/boot-clj/boot/wiki/Filesets#fileset-components
I'm still a bit confused. I've got some files in
, I want them to end up exactly as the same, in
- I don't yet know how to accomplish that
well, unless you want to process the files somehow
:asset-paths would be ok too
do I need to specify some task in the comp to get them to be copied over? or would you expect that to happen by default?
you just need to be aware that the contents of the directories that you add to those
*-paths things are added to the fileset not the directory itself
will basically cause something like
(set-env :asset-paths [“assets“])
cp assets/* target/
(And there’s no extra task required to have files copied over if they are in
hmm. If I have 0 tasks, nothing gets copied over. It's the inclusion of the
sass task that triggers the asset copy it seems
(serve :dir “target”) works if you use it with watch (ideally you serve from classpath though IMO).
I mean, if I just have
then no assets get copied over
(deftask build  (comp))
Null task is covered here https://github.com/boot-clj/boot/wiki/Tasks#the-null-task
but tbh I’m equally surprised and would have expected something to show up in
it does appear to work but only if I add back the 'sass' task, and I was trying to determine whether it was something weird in the sass task itself, but couldn't find anything
i remember some discussion about that but i don't remember what the trigger was supposed to be, but the idea was that something like boot by itself wouldn't cause target to be populated
@alandipert: but I still appreciate your point, I remember when I first realized that (comp) was identity, and (+) was 0, and (*) was 1
so I guess I'll just put the sass thing back and accept that this also triggers the boot assets copy, but I'd love to know if there's a more benign trigger that doesn't require a scss file to work !
I think the issue is that there’s no difference and thus nothing is synced: https://github.com/boot-clj/boot/blob/8b6ebea81e06d4e76e9e6ac23896c21e1e5b68ad/boot/core/src/boot/core.clj#L690
as soon as you have one task that changes something it will return something and then sync everything
I’m wondering, can I change
boot.core/sync-target without rebuilding boot itself? Like some
alter-var-root black magic?
should it only exist while boot is running? should it not exist while boot is running? etc
Also when we were wondering if it's writing to target dir which is causing fileset overhead
Hey folks! I can't get the browser repl to work for some reason. I've included cljs-repl in the build pipeline for my app. It seems to be starting a cljs repl at a random port (e.g. 55317). I'm serving the app with boot-http and I can see it open a websocket for that port. However, I can't open a REPL with "boot repl -c" followed by "(start-repl)". The latter simply starts another cljs-repl on <ws://127.0.0.1:0>, drops me in a "cljs.user=>" prompt. Everything I then type in results in this: java.io.IOException: No client connected to Websocket.
Oh, actually, that random port is the reload server socket, not cljs-repl. So it's not working at all.
cljs-repl task is injecting some client code into the cljs build, so if the order is wrong the client code won’t be in the build
Ha, thanks. I haven't used a browser repl before. Now I need to figure out how to access any of my CLJS code and do things more useful than (js/alert "Hello")
@pandeiro: agreen the full stack trace should go else where, i was looking into how the boot-reload file inject things into the cljs build, a tool like symphony profiler would be nice
usually the latest code from master needs to be processed in some way before your program can use it
so the best and simplest way is to build the jar locally and install it in your local maven repo
@martinklepsch: not sure, i've never seen it more than one line; i was just going by the recent discussions and the recent suggestion to use
@pandeiro: can you think of a case where you have 15 warnings that are not the result of some sort of cascade?
I agree that maybe there are smarter ways to handle this but I’m thinking if there’s so much stuff you probably messed up anyways and will fix all warnings at once.
And I also never recall seeing the Figwheel HUD cover a large portion of the screen (but I could be wrong about that)
And I think that is the best way, because I sometimes have like 200 warnings when refactoring something and I want to see them all
but yeah i can understand that... an 'X' button should be easy enough -- should I do that?
If you need the close button now, do it, but if you are not in a hurry we'll get it for free in few weeks
Yes, I did a quick test already: https://github.com/adzerk-oss/boot-reload/compare/figwheel
@juhoteperi: the only thing i would want would be to still fire some kind of event on the document when a reload event occurs
that's better for some things than --on-jsload because it's open and the task option is closed
And better for community to not put effort into two implementations doing the same
I plan on contributing some parts from our current implementation to Figwheel when I have time
I feel like the code we’re replacing with figwheel.client looks much easier to maintain than fw's
What’s the complex part about the file reloading? Maybe that’s something that could be put into a separate lib with a sane API and reused from FW & boot-reload
info about what the compiled js files are and how they relate to other compiled js files
Yes but Cljs is doing plenty of bootstrapping for Closure compiler in advanced mode that it doesn't do in none mode
Would be quite complicated and I doubt it's something that would be exposed on the API
so like if you're compiling multiple builds the cljs task should just make the optimal module configuration for you
@juhoteperi: ^ created the issue to further discuss. I’m not yet 100% convinced it’s the right step but that doesn’t have to hold you back of course.