<!-- If you'd like to propose an implementation for a large new feature or change then please create an RFC: https://github.com/sveltejs/rfcs -->
Is your feature request related to a problem? Please describe.
I tried to use Tailwind with Sapper. Even with the most basic setup the initial build time will go from ~2s to ~26s. I then tried to build the base Tailwind css outside of the Sapper build pipeline, this will take ~3s. The problem is that I'm not able to work on Tailwind theming etc. since I always have to wait 30s or with the other approach reload everything "by hand" instead of having sapper dev doing it for me properly.
I also tried copy pasting the generated Tailwind CSS into a Svelte components
<style global>… - still same build time increase. Therefore It shouldn't be caused by preprocessing etc. I think this is due to the fact that every css will be considered "handwritten" and all Svelte css processing kicks in, even though it's actually a frameworks css that most likely doesn't need or even shouldn't be further processed.
At least in the context of Sapper It would be easier to just import the css globally and have a proper dev build running "out of the box" instead of handling it outside of Sapper and try to get it in sync with the sapper build pipeline.
Describe the solution you'd like
<style plain> could work.
plain just indicates that the css shouldn't/don't need to be processed by Svelte.
Describe alternatives you've considered I will now try to write a rollup plugin to build Tailwind and then "inject" the result into an already processed css file in the Sapper build pipeline.
How important is this feature to you? With my current "full setup" Sapper it takes ~1m to rebuild Tailwind. This is pretty unusable, especially if you are aware that "normally" this should only take a few seconds.
Hello World REPL with unmodified Tailwind base CSS (With preprocess
global already applied - otherwise it wouldn't compile as It'll try to apply the component scope to every Tailwind definition - see: REPL)
@benmccann I know that solution. In terms of Sapper I couldn‘t reload the updated built global.css as it‘s cached by the service worker. You could exclude it there but then the global.css still isn‘t hashed e.g. Tbh that feels way to hacky for prod.
@Conduitry Yea also tried that. Then you can just use the rollup postcss plugin (which doesn‘t work with postcss8 atm 😬). But from there it‘s still hacky to get the extracted css into the sapper template and build pipeline
Currently I‘m using a custom rollup plugin that applies a postcss process on the corresponding svelte component css that‘s still In the rollup build pipeline. That way Tailwind gets build and applied after the svelte compiling. I‘m now back at 2-4s even with Tailwind updated instead of >1m. But that will only work for the client with
emitCss enabled, I think
I still would prefer to be able to bypass svelte css processing at compile time. It‘s super hard to use something like Tailwind with sapper without that option. I wanted to create and update the project specific theme, but atm it feels very clunky and hacky to get an „expected“ dev workflow, because svelte „must“ process every css, no matter what.