PostCSS plugin

[pavelloz]

Im very impressed by your work - need more testing to see if it really is as good as advertised in Tailwind projects.

If it is, im creating this issue, maybe even for myself if it wont be done when i finish testing, to create postcss plugin to make it easier to plug into existing asset pipelines.

.. Or maybe you will just merge your performance fixes to purgecss as you did with some of them, and then there will be no need for it :)

[leeoniya]

Im very impressed by your work

thanks! looks like we're both perf geeks.

need more testing to see if it really is as good as advertised in Tailwind projects.

i don't use tailwind myself, so very much looking forward to feedback.

create postcss plugin to make it easier to plug into existing asset pipelines.

doesn't postcss handle the parsing side of things, which would already negate a lot of the perf gained by using dropcss's css parser?

.. Or maybe you will just merge your performance fixes to purgecss as you did with some of them, and then there will be no need for it :)

this would either be difficult or impossible, since the libs operate on fundamentally different principles (at least from my cursory look). i think that it would be much easier to build a purgecss replacement on top of dropcss via [1] than vice-versa. however, this is probably not a good idea given [2].

[1] https://github.com/leeoniya/dropcss#accumulating-a-whitelist

[2] https://github.com/FullHuman/purgecss/pull/343#issuecomment-609112794

[pavelloz]

doesn't postcss handle the parsing side of things, which would already negate a lot of the perf gained by using dropcss's css parser?

Well, i think it depends on how we treat DropCSS as postcss plugin. I never wrote a postcss plugin, i assumed it can be plugged into a "onFinished" event and be done as a closing touch, when postcss spitted out everything it supposed to spit.

If thats not the case, then probably webpack (and insert your favorite asset bundler) plugin will be more appropriate for that task.

At the end of the day, maybe just dropcss-cli + .dropcss (as config) would be enough.

Im just advocating for having as much related tasks in one place as possible (hence postcss was my first idea, because tailwind lives in there already)

[leeoniya]

Well, i think it depends on how we treat DropCSS as postcss plugin.

yes, but i think once you're in webpack and postcss land, the perf aspect of dropcss will get eclipsed by everything else that has to run in that heavy toolchain. even if dropcss is 3-4x faster than purgecss, but on the whole still only accounts for 5% of the build time, then it's not terribly relevant in the big picture. if you treat dropcss as simply a more thorough css purging option, then it can still have some value, though.

i built dropcss for myself. my build script uses rollup, terser, cssobj-plugin-gencss & clean-css, it then crawls all its own express routes to grab & SSR the html, which it then feeds into dropcss for purging. the whole build script is about 300 lines that's quite specific to my setup but works exceptionally well with minimal dependencies or figuring out config options of 2 dozen plugins & 500 MB of dependencies. in addition to this, i have pretty aggressive CSP headers, which means the html has no style attrs and no inline <script> or <style> tags. i also don't need or care about sourcemaps and don't mind avoiding very-latest CSS features.

this is NOT what a typical Webpack or PostCSS audience expects. there are so many things that have to align just right to get the most out of dropcss in a general toolchain, that i think most people will not be willing to adjust their practices to make use of it. which means the only reasonable hope is that it can be used by static site generators - and certainly not most.

i imagine/hope that testing this against Tailwind in isolation will work quite well, but plugging into an ecosystem that expects sourcemaps, nice error messages, tolerant parsers, etc. will be very difficult, because dropcss does not cater to any of this - it is minimal and quite unforgiving.

[pavelloz]

Yep, my use case is very similar, in fact its identical.

I have ~300 html files and one css file that i want to cleanup, because tailwind.

When it comes to bleeding edge/sourcemaps - im with you ;)

And i see that you dont want to grow this project to become another Winamp 6 - im all for it. Its much better to do one thing and do it good. I was not suggesting expanding features/modifying how DropCSS works, only wrapping DropCSS with abstraction to be pluggable without this external script.

I would also say, with scope defined as good as DropCSS has, it doesnt really matter what typical webpack/postcss user expects. I would say typical webpack/postcss user has no idea about dropping unused css from their prod builds anyway. There is no tool that will make everyone happy, at best, there are tools that are good at doing what they say they do.

In my testing ill do my own cleanup-css script that will do exactly what your script is doing and with more experience, maybe better ideas come up :)

Anyway, closing, maybe one day it will be worth revisiting, maybe not :)

[leeoniya]

I was not suggesting expanding features/modifying how DropCSS works, only wrapping DropCSS with abstraction to be pluggable without this external script.

sure, i understand. i'm just not sure how generally useful this would be if it comes with a ton of caveats and does not play well with industry-standard workflows.

Anyway, closing, maybe one day it will be worth revisiting, maybe not :)

still, let me know how tailwind processing works out for you.