Redirect output-to to boot's tmp folders

[arichiardi]

If I understand the correctly, boot-figwheel is compiling the Javascript artifact directly to target-path at the moment. This is not very "boot-ey" because what you usually do is to use the fileset abstraction and then dump (in case) to target using the target task.

Maybe there is a reason why this works like this at the moment that I ignore, but would you be open to an alternative solution and PR?

[arichiardi]

I opened an issue on lein-figwheel because of a problem I found: bhauman/lein-figwheel#482

[ajchemist]

@arichiardi sorry it's late.

At the time I wrote the first version of boot-figwheel, there was no target task.
and yeah, I tried to make it "boot-ey", but at that time, such work was quite weird to me.
so I chose straightforward way.

If there is an alternative solution, I want to see it.

[arichiardi]

Hey it's not late and don't worry, simple and straighforward is better than nothing ;)
As you already know a running figwheel using the fileset/classpath is not straightforward at all.

It is an architectural problem, figwheel assumes that the file system is mutable whereas for boot it is not : the fileset is immutable by definition, once you add a folder to it, from boot.core/tmp-dir! for instance, it is copied over another "managed" folder which will be fed to other tasks down the pipeline.

Every time figwheel writes on the file system, there should be a mechanism to add the files to a the fileset, but unfortunately the fileset is already gone down the pipe after we bootstrap boot-figwheel.

I have tried a couple of hacks (fetching the resource temp folder boot uses and give it to fidwheel) but as @micha suggested on Slack this can wreak havoc as we are basically never updating boot's metadata if we just write directly in its managed folders.

At the moment I don't see another way that does not involve (unsafe) hacks, but I wanted to write down my thoughts here so that either @micha or @bhauman can pitch in.

[arichiardi]

There is also some nice WIP in boot-reload by @Deraen so I don't know if this is actually worth the effort: https://github.com/adzerk-oss/boot-reload/tree/figwheel, maybe I can just concentrate on that

[Deraen]

My opinion is still that proper solution will be to only just Figwheel client code, and use our own "server" (Boot tasks) which happen to provide compatible Websocket server. Based on discussions with Bruce about a year a go, we can implement changes in Figwheel client code if necessary. E.g. core-async dependency would make things tiny bit more complicated for us, so it might be useful to drop that from Figwheel code (not sure if still used, it was a year ago).

You are welcome to continue my work.

[azizzaeny]

+1 agree...,
can we ship this... https://github.com/arichiardi/boot-reload/tree/figwheel
lets make figwheel-client do All the things...

[arichiardi]

@azizzaeny sure, but as you can see I am still working on it ;)

[torgeir]

In the mean time I hacked this together to add the initially built js's folder into boot's folders with add-resource, so I can serve all static resources from public, both for dev and prod builds

(deftask frontend []
  (figwheel :target-path "target/public" ...)
  (file-utils/copy-dir-to-classpath "./target/public/js" "public/js"))

No havoc so far 😄

[Deraen]

https://github.com/boot-clj/boot-figreload

[arichiardi]

Shipped! 😄