Ok… finally I think I have managed to migrate everything to boot-clj from lein.

@ag Don't you miss figwheel ?

@romain I dunno yet.

I actually just realized that I forgot to port devcards… this should be fairly easy

😛

but if I really miss figwheel should’t I be able to make it work? Or it’s still would be a bit “clunky”?

I'm very new to boot. I just began modern-cljs tuto to get started and there is a live reload solution within

@romain oh yes, there’s boot-reload but I still was hoping to use figwheel - Bruce Hauman seems to be doing some cools stuff with it.

@ag it's really not much different with the boot tools. Nobody has taken the time to show the source code where the error is yet, but I don't think it would be complicated to add that to boot reload / boot cljs

I totally mixup on filesets. I want to know that how is the workflow of compiling cljs files and serving them via my own ring app, would be ?

should i serve the target directory ?

@lxsameer you want to serve resources. An example can be found at https://github.com/hoplon/demos/blob/master/castra-simple/src/app/handler.clj#L10

@ag I know that @richiardiandrea was looking into fixing something on boot-figwheel, I never used it myself.

@mynomoto can you please explain that line to me ?

@lxsameer that is using a compojure route to serve your resources on the "/" path. It will make everything on your resources available on the server and should only be used for dev.

So if you have "assets/images/pic.jpg" on your output fileset it will be served if you do a request to localhost:8000/assets/images/pic.jpg if you are running a server in the boot context.

The handler is passed to the server task here: https://github.com/hoplon/demos/blob/master/castra-simple/build.boot#L33

so this way / of my server map to fileset root ?

Yes

thanks i have to try it

I am actually now reconsidering fixing boot-figwheel, @juhoteperi actually already went through that path and suggested augmenting boot-cljs instead

@lxsameer https://github.com/adzerk-oss/boot-cljs/wiki/Serving-files this might also be helpful

@richiardiandrea what is your approach? i kinda got figwheel working in a task using figwheel-sidecar.repl-api I’m dumping the figwheel stuff into a resource which is being served via boot serve… my issue is that sometimes it does not reload the changes on save, i’m assuming cause the file sync takes place onto the temp fileset and figwheel notifies the browser too soon

i can throw this example up in a gist if you want

@naomarik yes the problem with the sync is exactly that, figwheel writes on dirs that are not managed by boot and given that boot-http serves from the classpath you won't see the new file sometimes

no no I have already been there

that path won't work unfortunately

i think if figwheel had a single option to delay browser notify

it would work

just until the time it takes to copy the stuff into the temp fileset

yes a hook after figwheel completes would be a patch to that...you can manually call boot functions that sync the mutable figwheel files with the immutable boot fileset

but it is a super hack

figwheel should only be used probably to compile on the fileset, disable all the watchers

and this is basically what boot-cljs does

so @juhoteperi is right when he says that it is probably better to add the figwheel client to boot-reload

@micha or @martinklepsch , I'm looking at implementing issue #450 (making 'task-options!` able to use delays). It seems like the most straightforward way to make it work would be to write essentially an apply wrapper that walks through all of the arguments to a task and forces it if it's a delay. Any thoughts on that approach?

hmm

or if you had another idea how to implement it, I'd love to hear it

let me refamiliarize myself with the issue, it's been a little while 🙂

ah yes

there was an issue with that approach

the issue with delays is that the user should be able to assume that task-options! merges options synchronously

and not asynchronously via delays

like if you put a delay in there and then call task-options! after that

i suppose we could have the macro know if the value is a delay

and keep wrapping in delays

i'm not sure I'm following you 😕

haha sorry that was terrible language

i mean the issue i see is this:

(task-options! foo {:bar (delay ...)})
(task-options! foo {:bar nil})

what should happen there?

does the delay just get replaced by nil?

okay, interesting point. That's what would happen currently with a non-delay value right?

there is also this form:

(task-options! foo #(update-in % [:bar] inc))

this could force the delay of course

but it's something to consider

yeah. okay, i see what you're getting at. that's the case where if we wanted to handle it "transparently" to the user, we'd wrap it in another delay and keep doing that...

right, that's a possible solution

but it's potentially surprising because that means the update to the task options will happen later than expected because of the delay.

yeah tricky

cool. good food for thought. I'll probably take a stab at just getting it working without considering that angle to get a better handle on what the solution will look like

great

hey guys… is there a way to “check” is serve is already running and "wrap" a task around it. So let's say I have two separate cljs profiles: dev and devcards - they both require pandeiro.boot-http/serve. I can't truly restart serve task. because of this: https://github.com/pandeiro/boot-http/issues/25. So what if in my task I check if ring-handler is running and if not then (serve) ❓

clojurescript optimizations failing after uberjaring, neither :simple nor :advanced works. Can someone give me an insight?