pyrmont 2020-03-09T00:54:19.041700Z

@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 ( 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! :)

pez 2020-03-09T06:16:23.044900Z

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.

pyrmont 2020-03-09T06:17:19.046100Z

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

pyrmont 2020-03-09T06:17:57.046900Z

It does have the disadvantage of having CSS rebuild messages appearing in amongst Figwheel's output.

pez 2020-03-09T06:46:26.047400Z

Thatโ€™s sometimes an advantage. ๏ฟผ๐Ÿ˜Ž

pyrmont 2020-03-09T06:54:59.047600Z

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.

pez 2020-03-09T07:47:44.059200Z

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).