I want to work on this issue, Would you like to assign me?

I wonder why you need to safelist here, it doesn't seem really needed for the email use case. Can you comment on that @summer-jordan?

Looking at it, the way to go here is to just delete it from the config and warn that the no behavior change will happen because of safelist. safelist doesn't make sense when we talk about inlining most styles, and much less in the email HTML environment.

I wonder why you need to safelist here, it doesn't seem really needed for the email use case. Can you comment on that @summer-jordan?

We are building a design system for emails using react-email. Keeping in line with our design system for web, we provide props for specifying margin and padding. These props are converted into classes dynamically. Since we do not have the tailwind classes appearing as a single, unbroken string, the spacing classes do not get converted into inline styles unless we add them to the safelist. https://tailwindcss.com/docs/detecting-classes-in-source-files#dynamic-class-names

Since a consumer of the design system could use any of the available spacing classes, we safelist all of them dynamically. We did not want to keep a list of all available spacing classes as that is quite verbose. I will update the code in my reproduction to demonstrate sometime today.

@summer-jordan can you make a minmal code example of what you mean here? Because it seems to me like it would work without the safelist as React Email only computes the styles from the final className, not from the code itself like normal TailwindCSS.

@gabrielmfern I was able to finally test this out and everything seems to work as you described. I removed the safelist in our codebase and all styles were still generated properly. Thank you for your assistance.