feat(css): allow scoping css to importers exports #19418
Conversation
sapphi-red
added
feat: css
p2-to-be-discussed
packages/vite/src/node/plugin.ts
Outdated
| /** | ||
| * If this is a CSS Rollup module, you can scope to its importer's exports | ||
| * so that if those exports are treeshaken away, the CSS module will also | ||
| * be treeshaken. | ||
| * | ||
| * Example config if the CSS id is `/src/App.vue?vue&type=style&lang.css`: | ||
| * ```js | ||
| * cssScopeTo: ['/src/App.vue', 'default'] | ||
| * ``` | ||
| */ | ||
| cssScopeTo?: [string, string | undefined] |
There was a problem hiding this comment.
I changed the interface to the one I felt easier to implement by proposal for now.
@bluwy What was the reason of your interface? I'm wondering the usage of allowing multiple files here.
There was a problem hiding this comment.
I don't have a concrete usecase. Was thinking that maybe there's some sort of unocss-like tool that generates scoped css derived from multiple modules somehow that could benefit from this. So I futureproofed it as a Record.
| @@ -323,6 +323,20 @@ export interface Plugin<A = any> extends RollupPlugin<A> { | |||
| > | |||
| } | |||
|
|
|||
| export interface CustomPluginOptionsVite { | |||
There was a problem hiding this comment.
I moved it here because it seemed CustomPluginOptions was changed to a type from an interface.
There was a problem hiding this comment.
I think this might probably be unintentional from Rollup side due to rollup/rollup#5591 🤔
There was a problem hiding this comment.
Made a PR here 👍
rollup/rollup#5850
| @@ -0,0 +1,7 @@ | |||
| <h1>treeshake-scoped (another)</h1> | |||
There was a problem hiding this comment.
@bluwy This file and the files in the barrel directory covers this case (#16058 (comment)).
There was a problem hiding this comment.
Reading the implementation, I believe you have the scoped CSS side effects set to false to fix this, but keep track of the scoped css styles map separately to bring it back? That's a neat trick. I guess a limitation of this is that it's harder to scope to multiple modules like you mentioned, but I think it's fine for now.
|
Maybe this PR could help to close #11855 |
|
@zeakd No, this PR is not related to that issue. This PR improves the behavior of "already" scoped styles. That issue asks for "a way to" scope the styles. |
| * cssScopeTo: ['/src/App.vue', 'default'] | ||
| * ``` | ||
| * | ||
| * @experimental |
There was a problem hiding this comment.
Added @experimental for now. The plan is to release this in 6.2 and stabilize it in 6.3 or 6.4.
| // a css module contains JS, so it makes this not a pure css chunk | ||
| if (cssModuleRE.test(id)) { | ||
| isPureCssChunk = false | ||
| } | ||
| } | ||
| } else if (styles.hasContentsScopedTo(id)) { | ||
| const renderedExports = chunk.modules[id]!.renderedExports |
There was a problem hiding this comment.
I think RenderedModule.renderedExports isn't implemented yet on rolldown. Should we check with them if this is a simple addition on rolldown side?
There was a problem hiding this comment.
Ah, good catch. Let me ask them.
Co-authored-by: Bjorn Lu <bjornlu.dev@gmail.com>
- Remove Twikoo's local style. - Remove local package of Artalk and Waline to minify styles This commit is because of unused comment styles in build packaged css. vitejs/vite#19418 might have helped, but Astro didn't use this experimental feature (withastro/astro#13420).
Description
closes #4389
closes #15497 (doesn't exactly fix it, but unblocks downstream to fix this)
This PR is based on #16058 but solves #16058 (comment)
Quoting the description from #16058 with some edits: