@dmarjenburgh: It's a few days past but I recently set up a Gulp workflow that sounds very similar to what @pez described. Here's my gulpfile.js
with the tasks I define (https://github.com/pyrmont/pondent/blob/master/gulpfile.js).
I'm using Tailwind in that project but you could adapt it pretty easily for any other CSS framework that has a PostCSS plugin. In development, it will start a watch on the directory with your CSS pieces and then gracefully end that watch when you quit Figwheel! :)
That's cool! In my case I haven't tried spawning them together like that. I have the watcher running in some terminal and start/stop figwheel independently. It probably depends a lot on the rest of your project and workflow, which method to choose.
I confess setting it up like this was purely so I had less to type and so I got the neat little summary at the end saying how long the process had been running :P
It does have the disadvantage of having CSS rebuild messages appearing in amongst Figwheel's output.
Thatโs sometimes an advantage. ๏ฟผ๐
True :)
Thanks for the tips. It seems it's quite normal then to have your figwheel project be an npm project as well, similar to shadow-cljs.
It might already be clear, but anyway, in my case only the css job is an npm project. Figwheel knows nothing about this, it only reacts on the css files coming out of it. My workflow is that I start this npm project in watch mode and then go Figwheeling. While I quite often do something to the Figwheel project that makes me need to restart it, the css watcher just keeps chugging on. I think right now it might have been running for 80 days straight. ๐ It has the disadvantage that I sometimes forget about starting it when I restart my computer, and spend some time wondering why Figwheel isn't hot reloading my css changes (.scss in my case).