Removing unused classes

[chrismwilliams]

Hi,

After reading your post on this boilerplate I thought I'd share that you can remove unused classes by adding them to tailwinds components layer in global.css like so:

@import-glob 'compositions/*.css' layer(components);
@import-glob 'utilities/*.css' layer(components);

You can also add files to tailwinds other layers as well, e.g. @import 'global/variables.css' layer(base);, but I not sure you gain anything by doing so.

Unfortunately, I can't find any reference to it on tailwinds docs to share, I just stumbled upon it when adding cascade layers.

Thanks for releasing this and hope it's helpful.

[Andy-set-studio]

Oh wow, that's handy! Thanks for sharing that info with us 🙂

[rol4nd909]

This option is really nice also.

[frankstallone]

TIL adding the URL to this issue in other repo references it. That seems like annoying noise in this issue. Will probably not do that in the future. Anyway — I created a PR for this. Thanks for sharing @chrismwilliams !! Nifty (undocumented) trick.

[chrismwilliams]

Apologies in advance also for the extra noise as it's not entirely applicable to this repo, although #7 may need to be modified depending on your use case, but I thought I'd add a bit more context to what I wrote above.

What I've found is if you are using a framework like Astro and you want to keep css bundles as small as possible, its preferable to not add blocks to the components layer, unless they are used site wide.

For example, let's say you have a .fancy-hero class that's only used on the index page. By adding it to the components layer, you are effectively preventing the framework (Astro) from optimising css by handing everything over to Tailwind. .fancy-hero styles would be bundled into every page.

In my own testing, and in terms of time vs performance, I found it best to just keep it to components & utilities, and handling blocks in a different way.

[rol4nd909]

Would love to see an example of this in a Astro setup.

[frankstallone]

Would love to see an example of this in a Astro setup.

I have this working in my adaptation of this Boilerplate for Astro. Feel free to open Issues to discuss Astro specific implementations there.

[frankstallone]

Apologies in advance also for the extra noise as it's not entirely applicable to this repo, although #7 may need to be modified depending on your use case, but I thought I'd add a bit more context to what I wrote above.

What I've found is if you are using a framework like Astro and you want to keep css bundles as small as possible, its preferable to not add blocks to the components layer, unless they are used site wide.

For example, let's say you have a .fancy-hero class that's only used on the index page. By adding it to the components layer, you are effectively preventing the framework (Astro) from optimising css by handing everything over to Tailwind. .fancy-hero styles would be bundled into every page.

In my own testing, and in terms of time vs performance, I found it best to just keep it to components & utilities, and handling blocks in a different way.

I'm more than willing to change the PR to whatever is most wanted or needed.

The CSS optimization you're talking about with Astro is coupling the CSS in the component itself, in the style tags — correct?

[frankstallone]

Just to be extra clear Set Studio can 100% close my PR because, technically, I shouldn't have opened it to begin with. It's not a bug, it's a enhancement and per the README is not valid.

This is a boilerplate that works for us, here at Set Studio, so please don’t propose changes.

[Andy-set-studio]

I really appreciate this issue and the PR. Thank you!

I'm gonna sit on it for a while though. I can't see us needing to remove blocks, compositions and utilities for more traditional setups because we generate a single bundle.

But, we are embarking on some more framework-based projects, so I'll test the PR on those and see how it runs!