Skip to main content
Chakra v3 accepts var() anywhere it takes a token value. So a Chakra system whose values are Livry’s custom properties rebrands entirely when the stylesheet changes — no provider swap, no re-render. Theme integration required: a pair whose library is Chakra UI. It builds tokens.css.

2. Build the system

DEFAULT is how a token can be both a value and a group. color.brand and color.brand.500 both exist in plenty of token sets, and a JavaScript object cannot hold a value and children under one name. DEFAULT is Chakra v3’s own spelling for exactly that — colors.brand.DEFAULT is addressed as brand.

3. Wrap your app

4. Use Chakra normally

Nothing names a colour. Swap the stylesheet and every Chakra component restyles — the provider and the system are unchanged, because they never held a value in the first place.

Generate it

The portal’s Integration tab generates the whole theme.ts from your actual Theme: your tokens, categorised into Chakra’s token groups, with var() values and your real fallbacks. Copy it once and edit freely. Which Chakra token each variable becomes is your naming decision, and Livry only guessed — but it stays right for every Variant, because a Variant changes values and never names.

Semantic tokens

Chakra’s semantic tokens work as usual, and they compose well with Livry: keep the raw values pointing at Livry, and express meaning on top.
Decide where meaning lives. Either model semantics in Livry as aliases — color.fg.accent aliasing color.brand — so a brand can override the semantic layer, or model them in Chakra as above, so they are fixed across brands. The first is more flexible; the second is more predictable. Doing both in the same theme gets confusing quickly.

Dark mode

Chakra’s _dark conditions work unchanged, because they select on the DOM rather than on token values. Point each side at its own Livry token: