search

domingues / rollup-plugin-css-chunks

Rollup plugin to extract CSS into chunks
MIT License
14 stars 8 forks source link

API to allow other plugins to provide css to output asset #9

Open jquense opened 3 years ago

jquense commented 3 years ago

This is partly an issue due to how Sapper extracts css so maybe better solved there (cc @benmccann)? I've been trying to write a rollup plugin that also transforms and concats individual css imported by JS. Something like css-modules and Sass (@tivac). The issue i've run into is there is no way to avoid having rollup-plugin-css-chunks re bundle css files i've already bundled together.

consider: files pre processed files in a chunk: A.mcss, B.mcss, C.mcss which get built into a single built.css. At the moment there is no mechanism to to have this plugin include built.css with all the other css files in the chunk and pass them them on to sapper. It gets specific to Sapper in that their splitting plugin looks in chunk.imports for files to include, however I can't add built.css to chunk.imports because css-chunks will turn it into a css @import which is unnecessary, and i can't insert my plugin after it b/c Sapper adds it.

I realize that a bunch of this is sapper specific, but my guess is the ultimate solution is probably here. Perhaps defining an interface via plugin meta to communicate new files (and the chunk they belong in)?

benmccann commented 3 years ago

Sapper automatically adds rollup-plugin-css-chunks and its own plugin to your Rollup configuration, which is pretty hacky. If/when https://github.com/domingues/rollup-plugin-css-chunks/pull/8 is merged, then my plan would be to remove both those plugins from being auto-added by Sapper and instead have the user manually add rollup-plugin-css-chunks to the Rollup configuration just like any other Rollup plugin. Then if you want to do some other CSS handling you can easily do that by changing the Rollup config yourself. If that would solve your problem like I think and hope it would, then I think we should probably go ahead and close this and focus on getting https://github.com/domingues/rollup-plugin-css-chunks/pull/8 in

jquense commented 3 years ago

Sounds like that would provide a path forward, though perhaps at the expense of some ease of use. Definitely makes sense to make that happen first. I do think there may be room here still for a inter-plugin api here since this is still likely to be an issue with other preprocessors (sass, less, etc). A unified way to have things before rollup-plugin-css-chunks add css to the bundle would be valuable.

benmccann commented 3 years ago

I don't think that rollup-plugin-css-chunks should be defining an inter-plugin API though. If that functionality were going to be added, it seems like Rollup should provide the plugin API to allow you to do it rather than making various plugins define and use a non-standard API that might differ between plugins or that not all plugins might support

tivac commented 3 years ago

Rollup does support custom module metadata now which could be leveraged to handle some of this, maybe?

jquense commented 3 years ago

Yeah I wasn't suggesting some out of band API, either accept cash files specified in module metadata or similar or just a way for upstream plugins to add stuff to chunks that the plugin sees. At the moment css-chunks must transform the file in order chunk it, which only works if there is a 1 to 1 transformation. Even still it fails in the modular-css case which transforms css files to javascript

jquense commented 3 years ago

thinking a bit more on this, merging #8 wouldn't address this. If an upstream plugin adds new css files to the bundle, they will be processed incorrectly same as they are now. Only files in chunk.imports produce injected links, nothing upstream from rollup-plugin-css-chunks can add to chunk.imports without having that file included as a @import in the chunked css

domingues commented 3 years ago

thinking a bit more on this, merging #8 wouldn't address this. If an upstream plugin adds new css files to the bundle, they will be processed incorrectly same as they are now. Only files in chunk.imports produce injected links, nothing upstream from rollup-plugin-css-chunks can add to chunk.imports without having that file included as a @import in the chunked css

Can you give a more concrete example, don't know if I'm following correctly. Currently if an upstream plugin produces JS that imports CSS, like what Svelte does, this plugin will process it. We can do something like this:

import 'a.css'
import 'b.css'

The @import is optional, by default is off.

jquense commented 3 years ago

Currently if an upstream plugin produces JS that imports CSS, like what Svelte does, this plugin will process it. We can do something like this:

That is only true if the file imports css in when the transform step runs. The concrete example here is that i have a plugin that compiles a few .my-css files to some number .js and .css during the generateBundle step, same as this plugin. At that step it's too late. rollup-plugin-css-chunks will see that the css files are imported by js files and try to include them, but since they weren't encountered during transform the css-chunks plugin doesn't have the css source for them. specifically this: https://github.com/domingues/rollup-plugin-css-chunks/blob/master/index.ts#L142 will return undefined