First of all this is a great effort to integrate tailwindcss with Drupal thank you.
The main.css
file gets more than 620KB unzipped and I suspect it will be mostly unused selectors
I have used https://github.com/spatie/laravel-mix-purgecss and I have created a minimal patch for it which I am attaching just for discussion. It works and it can reduce the file size down to only the used selectors.
Would you consider it ?
Right now I have it running with npm run build
but it should be run only before pushing to production
Would you create a different script npm run purgecss
with a new purgecss.config.js
configuration just for purgecss
how would you handle the need to have both main.css
optimized for production and a different main.css
for development ?
Please share your thoughts
Comment | File | Size | Author |
---|---|---|---|
use.purgecss.patch | 682 bytes | GiorgosK |
Comments
Comment #2
GiorgosKComment #3
opdaviesHi GiorgosK,
I agree that it would be good to reduce the size of the generated CSS if possible. I'm familiar with PurgeCSS and have used it on a few non-Drupal Tailwind projects.
The issue though with PurgeCSS from the perspective of using it with Drupal, is that not all classes are included in a theme's templates. They could be added via hooks in a theme's
*.theme
file, as part of a template in a parent theme, or as part of a module.If PurgeCSS were to be added and was executed against only the theme's templates directory, there's a chance that wanted classes could be removed inadvertently.
I'll give this some thought, though I think that it may be something to add to the theme's documentation for people to reference and implement on their own, rather than adding it to the default starter kit.
Comment #4
GiorgosK@opdavies thanks for the followup
Indeed it could end up being problematic if it is not well thought out.
Would you say it is safe to be searching in the
web/sites/default/files/php/twig
directory after the cache has "warmed up" ?Perhaps it could be run right after running https://www.drupal.org/project/warmer in a production environment.
Comment #5
opdaviesI've set up a repo at https://github.com/opdavies/drupal-tailwindcss-purgecss-test where I'm doing some experimentation and testing.
Currently running
yarn production
with PurgeCSS enabled seems to revert the base preflight styles.Comment #6
occupant@opdavies - it looks like https://www.drupal.org/project/tailwindcss/issues/3038830 updated tailwind to v.1.x (v.1.x was released last week I think?). In 1.x,
preflight
was renamed tobase
, among other utility name changes. https://tailwindcss.com/docs/upgrading-to-v1Not sure if that's the issue in #5 or not, but just in case.
Comment #7
opdaviesHi @occupant,
Yes, you're correct, though I'm using
@tailwind base;
already within the Drupal code at https://git.drupalcode.org/project/tailwindcss/blob/8.x-2.x/src/main.css and within the test repo at https://github.com/opdavies/drupal-tailwindcss-purgecss-test/blob/master....Comment #8
occupantHi @opdavies,
Ok, that's good. I've been testing the patch as well and it seems to be running ok for me. My styles are being output fine running
yarn production
(using the same command as here.Some thoughts re: #3.
Classes can indeed be added via module, parent theme or theme function in.theme
, but the CSS in the first two should also be provided by those if it's required - otherwise, how could it use it reliably for styling? Unless you're thinking of using another modules' selectors as styling hooks? In that case, that would be an issue.Edit: on second thought, it's obvious that's what you meant.
That said, I can think of two possible ways you could alleviate the problem:
/* purgecss ignore */
linkSince purgecss knowledge is already required when using purgecss, the first option seems preferable to me. I've tried it out and it's working fine in my tests.
Cheers
Comment #9
opdaviesComment #10
opdaviesComment #11
opdaviesComment #16
opdaviesComment #17
opdaviesClosing. Anything further will be done in #3186157: Use Tailwind's built-in Purge settings or a future issue.