4 ms·

I like tailwind, but I just used it for small side projects so far. Something I don't understand yet, is how you would use the "purgecss" feature in a large pr

by midrus 6y ago

I like tailwind, but I just used it for small side projects so far. Something I don't understand yet, is how you would use the "purgecss" feature in a large project or in the context of a company with several teams and a design system. For example, let's say we have a shared React components library, which has been built with tailwind. Should this shared library expose an already built and purged css file? Should each of our applications do its own purging? If so, how do I prevent the same m-1 to have two different values, one from the shared component library and another from my own application? If I have to add node_modules/my-library to the purge directories... Wouldn't that still leave styles for components I might not be importing in my application? Should I have a shared tailwind.config.js? These are the things that worry me about using tailwind in a larger context than a small/single project.

wishinghand 6y ago
> Should I have a shared tailwind.config.js? Yes. > If I have to add node_modules/my-library to the purge directories I believe the point of Tailwind is that you don't have these outer libraries anymore. If you need a piece of UI implemented, you copy/paste the markup with the required classes added. There is no `modal` class that completely modifies specific nested HTML. And if it's a complete palette/padding change, then that happens in the config. > ...how do I prevent the same m-1 to have two different values, one from the shared component library and another from my own application? `m-1` should never have different values in different contexts of the same project, unless the set of classes suffixed by `-1` is adjusted as a whole (ie- letting users resize the UI outside of the built-in browser magnification). > how you would use the "purgecss" feature in a large project Purge should happen in deployment, not in development. That way if a class is added that has never been used before, it makes it into the site without issue.
- midrus 6y ago
  > I believe the point of Tailwind is that you don't have these outer libraries anymore This is a total blocker for this use case then. As a member of one of multiple teams, I won't be able to convince anyone if we cannot have a shared, consistent "Datepicker", "AutocompleteInput", "TagInput", etc... Copy pasting these components is not an option for us.
  - wishinghand 6y ago
    > Copy pasting these components is not an option for us. Uhhh...why not? Have a repo with your versions of components if they're the exact same from project to project, and import them.
stefanfisk 6y ago
It really depends on how generalised your component libraries are. If you want to customise the color palette, you will need to use the same color classes in all libraries, which requires that the `colors` part of the config matches everywhere. Using a shared base config is probably a good start at least. As purging is only done for production builds, the purge content paths only need to be defined in that projects config. If you are using components from `node_modules` then you should add their paths to `purge.content`.
- midrus 6y ago
  Yes, but this wouldn't work either. I can add the node_modules/my-library path to be purged, but that means that I still will get included in my application EVERY class used in the component library, despite I might be using just every component or not. This is a major shortcoming for using tailwind in a company/corporate context in my opinion. I still like it for my own side projects though.
  - stefanfisk 6y ago
    I think you’ll find that there’s a common subset of classes that are used by most components, and that you quickly reach a point where adding new components hardly alters the built css file at all.

by midrus 6y ago

wishinghand 6y ago

> Should I have a shared tailwind.config.js? Yes. > If I have to add node_modules/my-library to the purge directories I believe the point of Tailwind is that you don't have these outer libraries anymore. If you need a piece of UI implemented, you copy/paste the markup with the required classes added. There is no `modal` class that completely modifies specific nested HTML. And if it's a complete palette/padding change, then that happens in the config. > ...how do I prevent the same m-1 to have two different values, one from the shared component library and another from my own application? `m-1` should never have different values in different contexts of the same project, unless the set of classes suffixed by `-1` is adjusted as a whole (ie- letting users resize the UI outside of the built-in browser magnification). > how you would use the "purgecss" feature in a large project Purge should happen in deployment, not in development. That way if a class is added that has never been used before, it makes it into the site without issue.

midrus 6y ago
> I believe the point of Tailwind is that you don't have these outer libraries anymore This is a total blocker for this use case then. As a member of one of multiple teams, I won't be able to convince anyone if we cannot have a shared, consistent "Datepicker", "AutocompleteInput", "TagInput", etc... Copy pasting these components is not an option for us.
- wishinghand 6y ago
  > Copy pasting these components is not an option for us. Uhhh...why not? Have a repo with your versions of components if they're the exact same from project to project, and import them.

stefanfisk 6y ago

It really depends on how generalised your component libraries are. If you want to customise the color palette, you will need to use the same color classes in all libraries, which requires that the `colors` part of the config matches everywhere. Using a shared base config is probably a good start at least. As purging is only done for production builds, the purge content paths only need to be defined in that projects config. If you are using components from `node_modules` then you should add their paths to `purge.content`.

midrus 6y ago
Yes, but this wouldn't work either. I can add the node_modules/my-library path to be purged, but that means that I still will get included in my application EVERY class used in the component library, despite I might be using just every component or not. This is a major shortcoming for using tailwind in a company/corporate context in my opinion. I still like it for my own side projects though.
- stefanfisk 6y ago
  I think you’ll find that there’s a common subset of classes that are used by most components, and that you quickly reach a point where adding new components hardly alters the built css file at all.