← 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:
accentandeyebrowon light:orange-600→orange-900- solid button text on light: white →
neutral-900 successon light:#10b981→#047857text-tertiaryon light and dark- new
badge-brand-text,badge-warning-text,badge-error-text, andinput-error-texttokens, 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:
| Was | Now |
|---|---|
--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--eyebrowand--nav-link-dropdown-text-hoverfor their own cases.The feature-item icon was the subtle one: it sits on a
bg-accent/15chip, 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 intests/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
exportstarget is missing from the packed tarball. This closes a real gap:./propertiesis 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.