Hi HN — I built TokenDrift, a CLI that scans a codebase for design system drift: hardcoded colors and off-scale spacing that quietly bypass your design tokens.

npx tokendrift .

It's zero-dependency Node, runs entirely locally, and gives you a Drift Score (0-100) plus a report showing exactly which files and lines are responsible. --share is opt-in and uploads only the report data (never source), if you want a link to paste in a PR or Slack.

Why I built it: every design system I've worked with rots the same way. Someone hardcodes #3B82F6 under deadline pressure, someone else does margin: 13px instead of the actual spacing scale, and six months later nobody can say when "mostly following the system" became "barely following it" — because nothing was measuring it.

Three real examples, not staged demos — I ran it against open-source repos and checked every number by hand before publishing: - Dub (dub.co): 82/100, 93% token adoption https://tokendrift-vedantyedes-projects.vercel.app/r/9GNaJ2M... - Formbricks: 87/100, 96% adoption https://tokendrift-vedantyedes-projects.vercel.app/r/JuKMkzk... - Twenty (CRM): 77/100, 80% adoption — one CSS file explains most of the gap: it declares its own tokens at the top and then falls back to a dozen+ different raw hex values in the rest of the file anyway. https://tokendrift-vedantyedes-projects.vercel.app/r/60K5vks...

Current scope: CSS/SCSS/JS/TS/JSX/TSX, auto-detects tokens from CSS custom properties, Tailwind config, or W3C token JSON. No Vue/Svelte support yet, no auto-fix (by design — I'd rather show you where the drift is than guess at a rewrite).

Source: https://github.com/vedantyede/tokendrift npm: https://www.npmjs.com/package/tokendrift

Happy to answer questions about the scoring formula, the false positives I found and fixed while building this (test files count as drift by default in a naive version — worth watching for if you build something similar), or anything else.