Runtime emittable color map for subsequent server-side parsing?

[wolfspyre]

Howdy all!

Firstly: Thanks for tailwind. This is really cool, and helping to make things better for a lot of humans around the world.
Y'all have a gold star in my book, fwiw.

I looked through the existing discussions, and the closest I found to what I'm lookin for is This Question asked a few years back: #6137¹. Which is CLOSE, but not QUITE what I'm thinking....

I'm looking for an elegant, forward-compatible way to have some programatic voodoo emit a truth-table of configured/currently possible to reference from tailwind's perspective color names/shades to their coresponding RGB values, to be consumed and referenced by other adjacent serverside components.

My use case is a hugo theme, wherein three tailwind colors are abstracted into a set of 'primary', 'secondary', and 'neutral' colors.

I've created some voodoo² for this theme which will allow a user to ask:

Heya! can you give me the rgb value of primary

or

Yo! what's the rgb value of secondary-900

or

Please give me the rgb value of blue-100

the voodoo will:

• Assess 'is this a theme-abstracted color'? (primary/secondary/neutral (( yes, I know neutral is overloaded. Nothing I can do about that really)) )

  • if so it will look at its theme-scoped truth-table to extrapolate

    You asked me for a value for "primary".
    In the context of color scheme FOO, primary extrapolates to the tailwind color-name: "blue"

• Assess if the user provided a weight/shade value, or if a sane default needs divination.

  • if the user didn't provide a shade/weight, a default fallback will be used after some light judgement and whining. ;)
  • Assuming we have a shade, and a color, for the sake of brevity:

• Next, the voodoo will reference a static datafile, which contains its lens into tailwind's color map and transliterate blue-100 into #dbeafe and return that.

• Then it will make you a sandwich, because it's nice like that.

This ... works... (for some value of works)

But, its datasource for supported/legitimate color names and shades/weights are static, and independent of tailwind... which creates an opportunity for these two sources of truth to diverge..

I'd like to avoid making problems for FutureMe™️ where I can.

Correspondingly, I'd like to ask if there's currently a way to, whilst running tailwind, ask (politely):

Hey Tailwind, While you're going through all my code and config, making my life easier n stuff, would you be so kind as to, while you're at it, to spit out a blob of json which enumerates, from your perspective, a list of currently-valid-to-reference colors and shades and their corresponding shades regardless of if they are used or not

In my perfect world, this output would look something like the attached twcolormap.json ... but I'd be open to whatever is reasonable/practical for tailwind to emit.

twcolormap.json

This would allow me to generate this lookup data in lockstep with the rest of the css of a site/context being processed, thus reducing the liklihood that I'd be oblivious to a divergence

The use cases for wanting a truthy lookup table are myriad; The most easily illustratable one being the generation of html meta tags and webmanifest assets, which require RGB values, not tailwind abstractions, and aren't really elegant to alter client-side³

Footnotes

1. (https://github.com/tailwindlabs/tailwindcss/discussions/6137) ↩

2. (https://github.com/jpanther/congo/pull/716) ↩

3. Please note: There are other use cases where this map would be helpful. I'd prefer not to rabbit-hole into a discussion around alternate ways to solve the exemplar use case, or, for example, debate the value of dynamic generation of such usually-static artifacts; as they're simply tiny illustrations of a need, rather than the entirety of one. ↩

[wolfspyre]

any suggestions on a/the proper way to have tailwind emit a programmatically consumable file
(json preferably... dear god no xml)
map of pretty-color-name to #hexvalcolor at instantiation would be appreciated.
I'd REALLY like to avoid plugins.

my ideal solution would be to have a set of flags to pass to the tailwind cli to have it emit a colormap from the active tailwind config, such that this map could be canonically generated by CI at build time, thus (mostly) preventing source-of-truth divergence.

but open to alternatives :)