You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you use postcss directly (via its CLI for example), it is a simple transform: input -> postcss (transform) -> output. It isn't relevant what format the input is in, or where it lives. As long as postcss can be told how to read it, it can transform it and be told how to write it.
This plugin however, seems to do nothing like that, having two strategies:
Extract CSS via postcss into a separate CSS file
Extract CSS via postcss into the <head> tag
Curious why this design has been chosen as it severely limits what postcss is for.
I don't want to extract anything, i want to run postcss against my input (sources) and produce an output (transformed sources). Having that happen in rollup is ideal, but that is all. No 'extraction', no 'injection', etc.
PostCSS already does this out of the box
In webpack projects, that is exactly how postcss integration works. You can tell webpack to pass the current inputs through postcss and bundle the outputs. If you want to pull the CSS out into files/chunks, thats a decision completely unrelated to postcss but rather for the bundler or a separate css plugin.
Basically what im asking for is extract: false, inject: false. I don't want it to do anything other than pass the file through postcss and use the output as the new file. From there, bundle it, split it out, whatever.
Otherwise i can't run postcss against embedded CSS (e.g. css inside JS files).
Is this plugin just outdated? since postcss may not have had custom syntax support back then.
IMO this is doing the job of two plugins and definitely shouldn't. webpack got it right:
A plugin to pass inputs through postcss and replace them with the output
A plugin to store CSS files alongside bundle output and update any references to point at their new paths
If you use postcss directly (via its CLI for example), it is a simple transform: input -> postcss (transform) -> output. It isn't relevant what format the input is in, or where it lives. As long as postcss can be told how to read it, it can transform it and be told how to write it.
This plugin however, seems to do nothing like that, having two strategies:
<head>tagCurious why this design has been chosen as it severely limits what postcss is for.
I don't want to extract anything, i want to run postcss against my input (sources) and produce an output (transformed sources). Having that happen in rollup is ideal, but that is all. No 'extraction', no 'injection', etc.
PostCSS already does this out of the box
In webpack projects, that is exactly how postcss integration works. You can tell webpack to pass the current inputs through postcss and bundle the outputs. If you want to pull the CSS out into files/chunks, thats a decision completely unrelated to postcss but rather for the bundler or a separate css plugin.
Basically what im asking for is
extract: false, inject: false. I don't want it to do anything other than pass the file through postcss and use the output as the new file. From there, bundle it, split it out, whatever.Otherwise i can't run postcss against embedded CSS (e.g. css inside JS files).
Is this plugin just outdated? since postcss may not have had custom syntax support back then.
IMO this is doing the job of two plugins and definitely shouldn't. webpack got it right:
cc @egoist
The text was updated successfully, but these errors were encountered: