Allow plugins to hook into `preprocessCSS()` about vite HOT 9 OPEN

What about writing a postcss plugin? preprocessCSS is currently only about Vite's internal CSS handling and isn't meant to be a general "run plugins to process CSS" utility.

from vite.

@bluwy

What about writing a postcss plugin?

We thought about this, but this won't work if css.transformer is set to lightningcss.

preprocessCSS is currently only about Vite's internal CSS handling and isn't meant to be a general "run plugins to process CSS" utility.

Yeah, this makes sense. In the case of Svelte, defining the custom Svelte preprocessor is definitly the better approach conceptually. It just means that we will have to hope that other users of preprocessCSS() provide an API for us to hook into their preprocessor list too to make it "just work" when someone adds the Tailwind CSS Vite plugin.

from vite.

Lightningcss also supports the visitor API which you could, though it looks like Vite's types may not be updated for it yet, and you'd have to maintain two implementations.

Is this only for vite-plugin-svelte? A Svelte preprocessor is definitely the better choice then, and if you already have a Vite plugin, you can add the preproceesor automatically like this: https://github.com/sveltejs/vite-plugin-svelte/blob/f06beb3836774b4a033a780712c7e84011698668/docs/faq.md#how-do-i-add-a-svelte-preprocessor-from-a-vite-plugin

from vite.

If I may tag along, I have a plugin I am trying to write to minify css template literals. Being able to hook into the same minification as standalone files would be a boon. Would this be a case you would consider @bluwy ?

from vite.

Do you mean const foo = css`.foo { color: red }` ? Wouldn't that be more of transforming JS code which would fit as a Vite plugin?

from vite.

@bluwy

The same issue exits with other users of the preprocessCSS() API, like Astro. The issue there is less urgent, since Astro passes through the CSS until it eventually hits the Vite transform hook (where as Svelte would be more strict about the input CSS) but it still means for the case of Tailwind CSS that some features don't work when the pre-processor is set to lightningcss—e.g. take a look at this issue).

I think what is confusing here most is that we add a transform() hook in the enforce: 'pre' phas, yet styles passed through the preprocessCSS() pipeline will already be processed beforehand—even though they will still eventually end up inside the transform() hook (potentially even double-processed?).

from vite.

Do you mean const foo = css`.foo { color: red }`? Wouldn't that be more of transforming JS code which would fit as a Vite plugin?

@bluwy Yes that is my intention. I have code that can parse out the template literal content and put in placeholders for the dynamic bits. I would like to use preprocessCSS, or similar, to minify that string.

Willing to move to a new issue so I dont derail this issue further.

from vite.

@bluwy Yes that is my intention. I have code that can parse out the template literal content and put in placeholders for the dynamic bits. I would like to use preprocessCSS, or similar, to minify that string.

@Lalem001 I'd suggest opening a GitHub discussion instead, I don't think preprocessCSS is the right fit here again. Its usecase is to only preprocess CSS, not completely transforming and minifying it.

The issue there is less urgent, since Astro passes through the CSS until it eventually hits the Vite transform hook (where as Svelte would be more strict about the input CSS)

@philipp-spiess I think Astro and Svelte should handle CSS the same, and both should go through Vite's transform hook at the end. Unless you mean Svelte is stricter than it'll strip out unused CSS?

I think what is confusing here most is that we add a transform() hook in the enforce: 'pre' phas, yet styles passed through the preprocessCSS() pipeline will already be processed beforehand—even though they will still eventually end up inside the transform() hook (potentially even double-processed?).

Yeah the intention here is to process them twice. preprocessCSS handles CSS preprocessors (e.g. sass, stylus, @import etc), and the rest of the Vite pipeline do the final URL replace, minifying, etc. This may cause some postcss plugins to be executed twice, but it isn't possible to know which phase they're only required in.

On the original topic, I think I understand the usecase, but it would be hard to implement it. We need the pluginContainer to run the plugins transform hook, but that's not possible inside preprocessCSS. It requires the dev server or the rollup build instance. And even if we can get that to work, performance would also be a concern. Manually calling it will also cause issues with missing this APIs or incorrect sourcemap mappings.

Given this, I still think the most viable choice is with a postcss plugin or the lightningcss visitor API. Or if Svelte's custom preprocess hook works for you, then I think Astro could also consider adopting something similar.

from vite.

@bluwy Yeah, that makes sense. I'll give the postcss plugin/lightningcss visitor approach a try or if there are similar features to the svelte preprocess hook on Astro etc.

Update: It looks like trying to use the visitor API will crash lightningcss for our setup. I have to try a few things to rule out it's because of our setup:

thread '<unnamed>' panicked at napi/src/threadsafe_function.rs:235:57:
called `Result::unwrap()` on an `Err` value: Error { status: InvalidArg, reason: "expect Function, got: Undefined", maybe_raw: 0x0 }
stack backtrace:
   0:        0x1406af184 - _napi_register_module_v1
   1:        0x140007e68 - <unknown>
   2:        0x14068f7cc - _napi_register_module_v1
   3:        0x1406b0488 - _napi_register_module_v1
   4:        0x1406afd70 - _napi_register_module_v1
   5:        0x1406b0c6c - _napi_register_module_v1
   6:        0x1406b07d0 - _napi_register_module_v1
   7:        0x1406b0734 - _napi_register_module_v1
   8:        0x1406b0728 - _napi_register_module_v1
   9:        0x1406dfc10 - _napi_register_module_v1
  10:        0x1406dff48 - _napi_register_module_v1
  11:        0x1406660e0 - <unknown>
  12:        0x1012dd268 - __mh_execute_header
  13:        0x1012db61c - __mh_execute_header
  14:        0x100f17d40 - __mh_execute_header
  15:        0x100e6c41c - __mh_execute_header
error: Failed to run "vite" due to signal SIGABRT

from vite.