Documentation

Documentation

@lightleaplabs/tokens 0.4.0

Release notes for @lightleaplabs/tokens 0.4.0.

← All @lightleaplabs/tokens releases

Public Beta compatibility policy

Minor change

Certify the Phase 1 component surface: complete custom-elements metadata, stable Storybook registrations, and improved keyboard and ARIA behavior.

Rendered colors change. Light-surface contrast fixes alter the default value of several tokens, so components render differently even though the API is backwards compatible:

  • accent and eyebrow on light: orange-600 → orange-900
  • solid button text on light: white → neutral-900
  • success on light: #10b981 → #047857
  • text-tertiary on light and dark
  • new badge-brand-text, badge-warning-text, badge-error-text, and input-error-text tokens, replacing shared colors that failed contrast on subtle backgrounds

Also adds a tabs-aria-label attribute to lll-feature-tabs so the tab list’s accessible name can be localized.

Breaking change

Freeze and document the public @lightleaplabs/tokens contract for the Phase 1 beta.

Breaking: twelve themed token pairs became single-value tokens. A token is themed because it has a meaningful per-theme answer, not because two values happen to differ. Corner radius and the terminal mock’s chrome — which is deliberately dark on any page theme — have no such answer, so publishing them as -on-light / -on-dark pairs advertised an override point that could never mean anything.

Migration — replace either suffixed name with the unsuffixed one:

WasNow
--radius-button-on-light / --radius-button-on-dark--radius-button
--radius-card-on-light / --radius-card-on-dark--radius-card
--radius-input-on-light / --radius-input-on-dark--radius-input
--radius-surface-on-light / --radius-surface-on-dark--radius-surface
--terminal-*-on-light / --terminal-*-on-dark (8 tokens)--terminal-*

Pairs whose two sides merely coincide today — the gradients, the transparent button backgrounds — are deliberately left alone. They are rebrandable surfaces where a consumer may well want to differ by theme.

Breaking: @lightleaplabs/ui no longer exports ./footer/props. The subpath pointed at Footer.props.js, which no build has ever produced — Footer has no Footer.props.ts — so importing it could only fail. Footer’s props are declared on the element itself.

tokens.docs.json is internal and no longer ships. It feeds an in-repo tooling script, has no export subpath, and carries no compatibility promise.

Also in this release:

  • Light-surface accents stay vivid at Orange 600, which is tuned for fills and glows rather than for text: on white it is 3.59:1, fine for a shape and short of the 4.5:1 that normal-size text needs. So anything that renders accent content now goes through a new Orange 700 pair instead — --accent-text (5.23:1 on white, 4.80:1 on the light page) for the accent badge, the animated words in <lll-heading>, the accent <lll-feature-item> icon, and the marketing form’s success copy, plus --eyebrow and --nav-link-dropdown-text-hover for their own cases.

    The feature-item icon was the subtle one: it sits on a bg-accent/15 chip, so Orange 600 on its own tint measured 2.95:1 — under the 3:1 that non-text content needs, even though the same colour passes 3:1 against the page.

  • The supported export list, every public override target, the internal --lll-src- mirrors, and the structural JS-only tokens are frozen in tests/public-token-contract.ts, and checked against the built artifacts by the first test suite this package has had.

  • The package-boundary verifier now fails when any exports target is missing from the packed tarball. This closes a real gap: ./properties is written by the ui build, so a tokens-only build left the subpath dangling.

  • The README documents import order, light/dark behaviour, Tailwind usage, what is and is not overridable, and the 0.x compatibility rules — including that a token rename requires a migration note like this one.

Minor change

Publish the free design tokens and Public Beta component library from public npm in the @lightleaplabs scope, licensed under the MIT License. Include third-party license notices in each published package, and support npm and pnpm installs without repository-only Bun lifecycle guards.

Minor change

Support first-class single-value design tokens, reject incomplete light/dark pairs during the build, and generate token documentation from the CSS-emitted token set. Motion tokens now expose one unsuffixed override each, while structural breakpoints use their canonical source values as literal Tailwind configuration and JS/type exports rather than consumer CSS override targets. Default-font tokens remain JS/type-only.

Patch change

Publish the public issue tracker URL in both package manifests and direct support documentation to the runnable examples and issue-reporting repository.

Patch change

Require Bun 1.4.0, and make the requirement enforceable.

The engines.bun range moves from >=1.3.0 to >=1.4.0 across every workspace package and every scaffolded template, so a generated project inherits the same floor the repo itself enforces. scripts/sync-bun-preinstall.ts — which is what keeps those fields in agreement — carries the new range, and the root package.json now pins packageManager: bun@1.4.0.

The preinstall guard now checks the Bun version, not just that the runtime is Bun. Neither engines.bun nor packageManager is enforced by Bun — both are metadata, and an install on an older Bun against either one succeeds silently. The floor was therefore advisory everywhere it appeared. The guard now compares Bun.version against the range and fails the install with the installed version and a remedy:

This repository requires Bun >=1.4.0. Installed: 1.3.14. Run: bun upgrade

For a project scaffolded by @lightleap/create, that turns an obscure downstream failure on Bun 1.3.x into a clear message at install time.

@types/bun is also pinned to ^1.4.0 instead of floating on latest, which had been resolving independently of the runtime in use.

Patch change

Point the README header at the live documentation site instead of “Documentation coming soon”, and add a direct component/token reference link alongside it.

Tag the npm-facing links back to lightleaplabs.com with utm_* parameters so referrals from the package pages are attributable. Covers the README logo and Website links and the homepage field in both packages; the campaign distinguishes ui from tokens, and the medium distinguishes the rendered README from npm’s own sidebar link. Documentation links are left untagged — the docs site has no analytics for the tags to reach.

These links ship inside the published tarball, so the scheme is fixed at publish time — changing it later requires a republish.

Esc