Heads up about `color` dependency

[MichaelAllenWarner]

I haven't actually tested this in your repo (sorry, fairly busy), but independently I found that using the color dependency in the Tailwind config seems to interfere with Tailwind's ability to correctly evaluate arbitrary color-values.

Specifically, I found that calling the color() function on a named CSS color—dodgerblue, say—would cause classes like text-[dodgerblue] and bg-[dodgerblue] to return invalid rgb syntax (just for named CSS colors that I called color() on). I imagine there's some shared-dependency mutation thing going on.

You might want to test for this problem in your project. I ended up switching to chroma.js.

[RyanClementsHax]

Thanks for opening the issue! I appreciate you looking out for me (I had no idea this could be a problem with color().

The good news is that named colors work with this plugin (I guess the version of color that I use handles the named colors? 🤷🏼‍♂️)

I actually happen to have an example of it being used in my personal site here.

I'll go ahead and close this since this plugin handles that case.

[MichaelAllenWarner]

@RyanClementsHax

Just to clarify the problem that I encountered: it's not that color-values defined using syntax like color('dodgerblue') weren't working, but rather that any named CSS-color I called with color() could no longer be successfully used in a Tailwind arbitrary-value class.

So for example, if I called color('dodgerblue') in my Tailwind config (without even doing anything with the returned value!), then arbitrary-value utility-classes like text-[dodgerblue] and bg-[dodgerblue] would subsequently fail.

To test if this is a problem in your project, you'd want to call color('dodgerblue') somewhere in your Tailwind config, and then see what happens when you try using the text-[dodgerblue] utility-class in a component.

Cheers