[agloe_dreams]

This was the only bit in tailwind we modified a lot in our Config. You really need to remove the default colors and define them as [Primary, Secondary, Neutral, Warning, Error, Success] and then add variants of each. Then it really works. I honestly think this should be a default config change/setup option in TW. Nobody with a Design System/Brand guidelines should be including the default colors in their app.

[MrJohz]

I agree that you don't need the default colours, and in fairness this is one of the things that Tailwind fairly explicitly encourages. That said, I also used to use "primary"/"secondary"/etc names for the colours, but since using Tailwind, I've been using colour names directly (e.g. "blue" or for fancier design systems "mirage-blue" or whatever their name for their specific custom blue is).

I find it's helped for a few reasons, but the big one is just that it's easier to keep the colours in my head - I'm not thinking in terms of "tertiary-alt-3" or something, I'm looking at a design and going "that's green, which green? This green". I have more discussions talking about colours in terms of the standard English colour names than I do in terms of those colours' purposes in the design system, so the colour names seem more practical.

That said, I agree that spending some time switching the colours to whatever design system you're using us very useful. Another trick I've found is starting off a project just using raw CSS values (the `p-[8px]` syntax), and then when the basic designs are done based on whatever the designer has sent, getting a list of all the custom classes you've got and using this to define what the standard units are. This is helpful when the design guide isn't specific on these details, and the designer is being more freeform.

[nwienert]

The biggest thing I've learned in making Tamagui is that the ideal setup is not to really have specific colors at all (unless you really really are just doing a one-off single color thing), but instead to let themes handle this (essentially a classname that changes out a set of CSS variables).

Then you can do things like `color1` (or `primary1` or `secondary2`) etc, keeping them generic. With this setup you can then re-theme any area instantly, no dark-x or light-x, no green-x. You can inverse an area to be light on dark, you can change the color out if need be.

We even go one step further (as an optional feature) where you can avoid the `color1` for many cases and instead use `color`, `colorHover` etc, which allows for having themes that change contrast or the strength of their various alternate states, but that's another story.

The site itself shows off some of this, but it's really quite nice. Now your "Notice" box can be alert style, or success style, with just a single `<Theme name="alert">`.

[agloe_dreams]

This is part of why we started down this path. We have a self-white-labeling product based on a JSON file loaded at runtime. Having this sort of theming is kinda a pre-req. but we are totally not blind to the ways we can play with it.

[agloe_dreams]

I would argue that all of what you just said is your designer failing you. For us, we defined the base sizing and colors beforehand and the designer works from there. We also use named color variables and themes in Figma such that an element with a background color shows the named color so I can just type in the same name in TW. Putting design and development at the same table on day one and getting both sides to speak the same language definitely speeds development and I really do think your life would be better for it. While your designer has you stuck picking 8px, 10px or 12 px, my source mocks are just .5rem or 1 rem and I can look at a design at this point and add the right value without even checking. You deserve better from your designer; them being 'freeform' is just them doing whatever feels cool this week and a whole lot of inconsistent values.

[gedy]

This is something Bootstrap does right, and has kept us away from Tailwind so far.