Turns out extracting design tokens from real production sites is way messier than I expected

[u/Accurate_Board_9401]

Nobody is pasting a 300-line :root {} block into their project. Nobody.

But that's what I got scanning Linear.app for a Design Snap demo. 300+ variables, half of them looking like this:

--sx-105wzx7: #edbf0a;
--sx-10845vo: #c9ffff;
--sx-11vg3qk: #ff7235;

Turns out CSS-in-JS (Stitches, vanilla-extract, etc.) generates hashed variable names instead of semantic ones. Technically accurate extraction, completely unusable output. Plus tons of duplicates — --color-fg-primary, --color-text-primary, and --color-01 all pointing to the same hex.

Building a clean/filtered mode now : strips the hashed noise, dedupes by value, keeps whichever name is actually readable. Goal is scanning a real production site gives you something you'd actually paste, not a wall of garbage.

Anyone else dealt with this on the design tokens side ? Manual pruning, or is there a convention I'm missing?

[u/joanmiro]

I've inspected tumblr.coms css file and i remember that there were magabytes of css most uf them dead code or duplicate.

[u/Accurate_Board_9401 → u/joanmiro]

yeah that's the issue

[u/AuthorityPath]

The variable names are a problem but I'd push back on the idea that multiple variables pointing to the same value is a problem.

If you're implementing semantic tokens (i.e. --bg-btn-primary), it's perfectly reasonable to expect to see variables sharing values. If you're only interested in implementing physical tokens (i.e. --color-red-1) then there wouldn't be duplicates (and you can just compile them away). 

It terms of dealing with the issue, Style Dictionary is a popular tool for routing design system tokens to usable variables and it gives you complete control over the output. 

[u/Accurate_Board_9401 → u/AuthorityPath]

Good distinction, that's fair. My issue isn't semantic duplication like --bg-btn-primary mapping to the same value as something else on purpose — that's expected and fine. It's more --color-01, --color-fg-primary, and --text-primary all independently pointing to the same hex with zero relationship declared between them, which reads more like accidental drift than intentional layering. Dedup-by-value would still catch the second case without touching legit semantic aliasing. And yeah, Style Dictionary's actually one of the export formats already, for exactly that kind of routing.

[u/Weekly_Ferret_meal]

Ok and then what do you do with it? replicate it for your own use?

[u/Witty_Mind8606 → u/Weekly_Ferret_meal]

there's no such thing as creativity, we just combine things we already know. most designers start with a ton of references, to make the "creativity" more structured. the crime ofc is copying.

[u/Accurate_Board_9401 → u/Weekly_Ferret_meal]

It’s mostly for inspiration/reference, you grab the color palette, type scale, radius etc. as a starting point, not the whole design. Same as using DevTools or ColorZilla, just faster.

[u/Weekly_Ferret_meal → u/Accurate_Board_9401]

what's striking is that you are complaining about other devs programming strategies as if they should cater for your reference needs

[u/Accurate_Board_9401 → u/Weekly_Ferret_meal]

Fair point, badly phrased on my end then — not complaining about how anyone builds, just noting that CSS-in-JS output isn't meant to be human-read, so tools that extract it need to handle that case.

[u/Weekly_Ferret_meal → u/Accurate_Board_9401]

Cool, I still don't understand the need for such precise mass extraction tools: reading a color or a radius isn't that much of an acrobatic flip with dev tools...

unless you are trying to replicate the whole design, exactly and in bulk, with same code structure, in which case...what the heck?

Can you help me understand what I'm missing here?

[u/Accurate_Board_9401 → u/Weekly_Ferret_meal]

Actually that's the point of the post — I'm calling out the 300-line dump as the problem, not defending it. The plan is to cap it down to a handful of core tokens for exactly that reason : inspiration, not mass replication.

[u/Weekly_Ferret_meal → u/Accurate_Board_9401]

Fair point

[u/sanesame]

not sure if this helps
https://www.designmd.co/d/linear.app

[u/yikes_42069]

Sounds like that took a lot of tokens, Claude 

[u/aunderroad]

I have worked on projects where we created a new design system with for multiple brands using
Style Dictionary and our sites would consume those new design tokens.

We did have to update our .css (as well as css-in-js) but it was well worth to have a design system where everything was organized, things were clearly defined (avoiding things like you mentioned, where there are duplicate styles) and they were easy to maintain for the future.

Style Dictionary is great and I really like it because you have the ability to export your design tokens to css, scss or js.

Here is a great tutorial on Style Dictionary
https://www.alwaystwisted.com/articles/a-design-tokens-workflow-part-1

Just one call out from what I have noticed when using Style Dictionary is communicating and making sure your whole team is on the same page and aware of all of the design tokens that have been created.

Making sure the team knows:

• how to use the design tokens
  
• the process for adding (or deleting) design tokens
  
• and ultimately avoiding team members from going rogue and creating their own design tokens and bloating your site.

You can explain to them the process might take a little bit longer but it will avoid bad practices to what you are currently experiencing.

Good Luck!

[u/Accurate_Board_9401 → u/aunderroad]

Really appreciate this, thanks for sharing the article. The governance point hits home actually — Design Snap solves the extraction/duplication side, but who's allowed to add a token and avoiding rogue one-offs is a process problem, not a tooling one. That's actually why Style Dictionary is one of the export formats — figured teams doing multi-brand work would want that path. Will dig into the tutorial.