onsystem@0.9.1

onsystem 0.9.1 reads tokens the way your stylesheets apply them, and no longer slows down on very long values.

• shadcn/ui's Tailwind v4 codemod theme (--color-destructive: hsl(var(--destructive))) is read as the token destructive, so text-red-500 is fixed to text-destructive, not text-[hsl(var(--destructive))]. Stylesheets imported one after another apply in CSS order, and when components.json names a stylesheet in another package (as cal.com's does), the app's own stylesheet is read first.
• A Tailwind v3 config keeps Tailwind's default radius scale: rounded-[12px] is fixed to rounded-xl, not rounded-lg. In a v3 project with no radius tokens of its own, no-hardcoded-radius now runs against that scale, so check can report warnings it did not before.
• A class with an arbitrary length thousands of digits long (p-[999…9x]) took about 25 s to check at 100,000 characters, in check, check_ui, the ESLint plugin and the Action; it now takes a few milliseconds. A var() whose fallback holds calc() or another var() now has the fallback's value. onsystem export --format dtcg keeps a __proto__ token and no longer adds properties to every object in the process.
• Thanks to @Aaqibhafeezkhan (get_component explains when a project has no components, #234) and @Golden007-prog (a failed warning cap is explained in every CLI output format, and JSON and SARIF stay parseable, #235).

---

Patch Changes

• #234 643bc6f Thanks @Aaqibhafeezkhan! - Explain when a project has no design-system components available.

• #235 65f91f5 Thanks @Golden007-prog! - Explain a failed warning cap in every CLI output format: a GitHub error annotation, or a message on stderr that leaves JSON and SARIF output parseable.

• #232 a965061 - A long length or color no longer slows onsystem down. A class with an arbitrary length thousands of digits long, such as p-[999…9x], took a second to check at 20,000 characters and about 25 seconds at 100,000, in check, the MCP check_ui tool, the ESLint plugin and the GitHub Action: the pattern that reads a length tried every way to split the digits. It now takes a few milliseconds. The same goes for token values: a length, a var() with a fallback, or bare HSL or RGB channels in the design system's stylesheets or Tailwind config, and typography, spacing and radius values in onsystem export. A var() whose fallback holds calc() or another var() now has the fallback's value, inside calc() too: calc(2 * var(--gap, var(--space-2))) is read as a length, and calc(var(--gap, var(--space-2)) + 1px) no longer drops the + 1px.

  onsystem export --format dtcg keeps a token whose path has a __proto__ part, such as --color-__proto__, under a "__proto__" key of its group. It was left out, and a name such as --__proto__.polluted added a polluted property to every object in the process that ran the export.

• #201 ee231a8 - Tokens are read the way the stylesheets and the Tailwind config apply them, in four cases where they were not.

  • An @theme color that wraps a variable of bare channels, as shadcn/ui's Tailwind v4 codemod leaves a v3 theme (--color-destructive: hsl(var(--destructive)) with --destructive: 0 84.2% 60.2%), is the token destructive with its class. The class and the color were on two tokens, so every fix was an arbitrary value: text-red-500 was fixed to text-[hsl(var(--destructive))], and now to text-destructive. rgb(var(--x)) over RGB channels counts too. An @theme value that names another variable takes its color: with --color-brand: var(--color-blue-600), bg-blue-600 suggests bg-brand.
  • Stylesheets imported one after another apply as CSS applies them: a later @import overrides an earlier one, and the importing stylesheet's own rules override both. With @import "./base.css"; @import "./brand.css";, --primary came from base.css, so bg-[[#171717](https://github.com/dgesteves/onsystem/issues/171717)] was fixed to bg-primary, which renders brand.css's color.
  • A Tailwind v3 config that extends borderRadius (as shadcn/ui's does, with lg, md and sm), or sets none, keeps Tailwind's default scale: rounded-[12px] is fixed to rounded-xl, not rounded-lg (8px), and rounded-b-[24px] to rounded-b-3xl, not rounded-b-full. A theme.borderRadius outside extend replaces the scale, unless it spreads defaultTheme.borderRadius into it. No default step is added when the scale cannot be read: a step of the config has no known size, because no stylesheet read sets the variable it uses (var(--radius)); the config takes a preset, a theme or the whole config from an installed package (presets: [require("@acme/preset")], theme: require("@acme/theme"), module.exports = require("@acme/tailwind-config"), { ...base, content }), which may replace the scale; or borderRadius is set from a variable, a function or a spread other than defaultTheme.borderRadius. Tailwind's own modules (tailwindcss/defaultConfig) do not count. A theme that is a module of the project, or spreads one (theme: require("./theme"), theme: { ...require("./theme") }), replaces the scale with its own borderRadius, and presets: [] leaves out Tailwind's default config, so neither keeps the default steps unless a theme.borderRadius spreads them back in. Nor is one added in a Tailwind v4 project that reads the config through @config, which has v4's scale. In a Tailwind v3 project with no radius tokens of its own, such as Dub, no-hardcoded-radius now runs against that scale, so check can report warnings it did not before.
  • When components.json names a stylesheet in another package, as cal.com's names coss/ui's, zero config also reads the app's own stylesheet first (styles/globals.css, app/globals.css and the others it looks for without components.json), and the named one through it when the app's stylesheet imports it. cal.com's own tokens (text-subtle, bg-emphasis, rounded-cal) were not read, and color fixes named coss/ui's tokens instead. When the app's stylesheet imports Tailwind v4, the spacing and radius rules use Tailwind's scale, as in any Tailwind v4 app.