@kong/design-tokens

Kong Design Tokens for Konnect, via Style Dictionary.

• Token Tiers
  • Semantic tokens
  • Component tokens — names only, value-less
  • Themeable token list
• Themes
• Tokens
  • Token Formats
  • SCSS
  • CSS Custom Properties
  • JavaScript
• Usage
  • Installation
  • Standalone components
  • Host applications
  • Kongponents
• Updating Tokens & Local Development
  • Directory structure
  • Token Requirements
  • Creating a new theme
  • Previewing a theme
  • Theme $description authoring rules
  • Development Sandbox
  • Lint and fix
  • Build for production
  • Token Update Workflow
  • Committing Changes
  • Approvals
  • Package Publishing

Token Tiers

The @kong/design-tokens package uses a two-tier exported token taxonomy.

| Tier | Source directory | Examples | Exported as | |------|-----------------|----------|-------------| | Semantic | tokens/source/** | --kui-color-background-primary, --kui-space-40, --kui-border-radius-30, --kui-method-color-background-get | CSS custom properties, SCSS variables, JS constants | | Component | tokens/components/** | --kui-button-border-radius-medium, --kui-button-color-background-primary, --kui-button-shadow-focus | Included in KUI_THEMEABLE_TOKENS — no CSS value |

Alias tokens (themes/<name>/<name>.alias.color.json, one per theme) form a third internal category. They hold the raw palette values (hex colors) that semantic and component tokens reference. They are never exported — they exist only so Style Dictionary can resolve {color.alias.blue.100} references at build time.

Semantic tokens

Everything in tokens/source/ is a semantic token — it has a concrete value and is exported to all formats (CSS, SCSS, JS). This includes:

• Scale tokens — --kui-color-*, --kui-space-*, --kui-border-radius-*, --kui-shadow-*, --kui-font-*, etc. Named after the design dimension they represent.
• Concept tokens — --kui-method-*, --kui-status-*, --kui-navigation-*, --kui-icon-*. Named after a cross-cutting UI concept (HTTP methods, status codes, navigation chrome, icons) rather than a design dimension. Each family lives in its own folder under tokens/source/ (method/, status/, navigation/, icon/), following the same pattern as the scale folders. They are plain semantic tokens, valued and exported exactly like scale tokens. These are not component tokens even though they're used inside components.

IMPORTANT — primary and accent colors must be overridden in the Dev Portal

The primary tokens (--kui-color-background-primary, --kui-color-text-primary, --kui-color-border-primary) and the accent tokens (--kui-color-background-accent, --kui-color-text-accent, --kui-color-border-accent) — plus any future brand-derived color used the same way — ship a Kong-branded default value. The Kong Konnect Dev Portal (kong-konnect/portal) renders customer-branded UIs, where each customer configures their own brand/theme color.

Because these tokens carry a default, that default will leak Kong's brand color into the customer's portal unless the portal overrides it. Therefore, whenever a primary- or accent-like brand color token is added, renamed, or its default value changes, the kong-konnect/portal customization plugin must be updated to override the token with the portal's configured theme color variants so the design-tokens default never reaches the rendered Dev Portal.

Component tokens — names only, value-less

Component tokens (--kui-button-*, --kui-card-*, --kui-input-*, --kui-badge-*, …) live in tokens/components/ and are declared without any CSS value — they are purely override slots. Every Kongponents component uses them in a var() fallback chain:

border-radius: var(--kui-button-border-radius-medium, var(--kui-border-radius-30, $kui-border-radius-30));
//                 ↑ component token (empty by default)   ↑ semantic fallback        ↑ SCSS literal

When a theme writes --kui-button-border-radius-medium: 999px, only buttons go pill-shaped. Inputs and other components keep their semantic default. When no theme writes the token, var() falls through to the semantic default — byte-identical to the un-themed render.

Themeable token list

The ./tokens/themeable-tokens subpath exports KUI_THEMEABLE_TOKENS — a typed readonly tuple of every --kui-* custom property name that a theme may meaningfully override. It combines both semantic tokens and value-less component tokens.

import { KUI_THEMEABLE_TOKENS } from '@kong/design-tokens/tokens/themeable-tokens'

// Each entry is a `{ name, description, category, value }` record.
// Derive a union type of all valid theme keys from their `name`s:
type ThemeToken = typeof KUI_THEMEABLE_TOKENS[number]['name']

Themes

Pre-built theme CSS files activate a complete set of token overrides via a data-kui-theme attribute on any element. Load a theme CSS file and then set the attribute on the root element (or any subtree element):

<!-- In your HTML template or equivalent -->
<html data-kui-theme="electric-lime-day">

// Load the theme CSS — webpack/Vite will bundle it
import '@kong/design-tokens/themes/electric-lime-day.css'

// Switch the active theme at runtime
document.documentElement.setAttribute('data-kui-theme', 'electric-lime-night')

Available themes: classic-day, classic-night, electric-lime-day, electric-lime-night. classic-day is the default look (identical to the unthemed :root exports); classic-night is its dark counterpart.

Each theme CSS file uses @layer kui.theme { [data-kui-theme="name"] { ... } }. This means customer :root {} overrides (which are unlayered) beat the theme automatically — no !important or special selectors needed.

To respond to the system dark-mode preference, listen to the prefers-color-scheme media query in JS:

const mq = window.matchMedia('(prefers-color-scheme: dark)')
const applyColorScheme = (dark: boolean) =>
  document.documentElement.setAttribute('data-kui-theme', dark ? 'electric-lime-night' : 'electric-lime-day')

applyColorScheme(mq.matches)
mq.addEventListener('change', e => applyColorScheme(e.matches))

You can also import the theme objects as JavaScript for runtime composition or for use with Kongponents' applyTheme / defineKongponentsTheme:

import { electricLimeDay, electricLimeNight, classicDay, classicNight } from '@kong/design-tokens/themes'

Tokens

View the lists of available tokens here, or keep reading for more information.

Token Formats

The @kong/design-tokens package exports tokens in multiple formats:

• SCSS
• CSS Custom Properties
• JavaScript (ESM, CJS, and JSON), along with corresponding TypeScript types

Exports are available from the package root meaning you do not need to include the dist/ directory in your imports:

// Notice that for JavaScript/TypeScript, we can just import from the root
import { KUI_COLOR_BACKGROUND_PRIMARY_STRONG } from '@kong/design-tokens'

SCSS

SCSS Variables

SCSS variables can be utilized in your project's SCSS files or in-component style blocks (this assumes your app is already configured to compile Sass).

To use the SCSS variables, you need to import them into your component or app stylesheet so they are available throughout your project utilizing one of the methods below:

Import into your app or component's stylesheet or style block

@import '@kong/design-tokens/tokens/scss/variables';

Globally import with Vite

If your component or application utilizes Vite to build and compile, you may add the following configuration to your vite.config.ts to import the SCSS variables into all components within your project

// vite.config.ts
import { defineConfig } from 'vite'

export default defineConfig({
  css: {
    preprocessorOptions: {
      scss: {
        // Inject the @kong/design-tokens SCSS variables to make them available for all components.
        additionalData: '@import "@kong/design-tokens/tokens/scss/variables";',
      },
    },
  },
})

SCSS Map

The package also exports a SCSS map of the tokens from the @kong/design-tokens/tokens/scss/map file

$tokens-map: (
  'kui-color-background': #ffffff,
  // ... etc.
);

CSS Custom Properties

You may scope your CSS variable overrides inside the :root selector as shown here, or inside any other valid CSS selector.

Two versions of the CSS Custom Properties are exported from the package.

@kong/design-tokens/tokens/css/custom-properties.css

This file exports all available custom properties with the values set to their actual raw value.

@kong/design-tokens/tokens/css/custom-properties-list.css

This file exports the custom properties with a value of initial; mainly used for IDE auto-completion where you do not actually need the token values.

IMPORTANT: You should never import the @kong/design-tokens/tokens/css/custom-properties-list.css file in your host project.

While CSS variables are utilized in Kong's repositories to allow for CSS customization, the variables themselves are never actually provided values or imported from this package.

The purpose of the @kong/design-tokens/tokens/css/custom-properties-list.css file is to provide a list of all available CSS variables, to utilize alongside auto-complete extensions in your IDE, etc.

If you want to customize default token values, provided the element(s) in question utilize CSS variable fallbacks, simply set the variables from this list to your desired value within your host application, scoped inside your desired CSS selector, and it will override the default value.

<style>
// You may scope the variable to `root:` to impact the whole application...
:root {
  --kui-color-text-primary: green;
}

// ...or scope the variable to a specific container to keep the changes isolated
table .my-table-row {
  --kui-color-text-primary: purple;
}
</style>

JavaScript

JavaScript Variables

JavaScript variables can be utilized in your project's component files, or other JavaScript/TypeScript files.

To use the JavaScript variables, simply import the variables you need into your component/file:

// Notice that for JavaScript/TypeScript, we can just import from the root
import { KUI_COLOR_BACKGROUND_PRIMARY_STRONG } from '@kong/design-tokens'

JSON

The package also exports a JSON file of all tokens from @kong/design-tokens/tokens/js/tokens.json

Usage

Installation

In your host project, install the package only as a devDependency:

pnpm add -D @kong/design-tokens

Why a devDependency?

This package is intended to be consumed by a host component or application that will be compiled before publishing. This means when the component or app is compiled, any tokens it consumes (e.g. SCSS tokens, JavaScript variables, etc.) will be replaced during the build with the static token value.

This strategy alleviates the need for a consuming application to need to install the @kong/design-tokens package when using a component that utilizes the tokens under-the-hood.

Stylelint Plugin

This package used to bundle a Stylelint plugin. It is now a standalone package. See @kong/stylelint-plugin-design-tokens.

Standalone components

The primary consideration when using Kong's design tokens in components is to determine if the component needs to allow for downstream customization.

If your component does not need to offer any customization, only utilize the SCSS and JavaScript design tokens in your component.

If your component does want to offer customization, you will want to reference the corresponding token CSS variable with a fallback SCSS variable.

Component Example

As an example, in Kong's Kongponents Vue component library, we want to offer deep levels of customization to allow for an external host application to override component styles. Enabling customization is easy by using the Kong Design Token's CSS variables with SCSS variable values as the fallback.

<style lang="scss">
// Import SCSS variables
@import "@kong/design-tokens/tokens/scss/variables";

.my-component-class {
  /**
   * When setting a CSS variable value to a SCSS variable, you need to
   * interpolate the SCSS variable. Interpolation can be used
   * almost anywhere in a Sass stylesheet to embed the result of a
   * SassScript expression into a chunk of CSS.
   * Just wrap the expression in `#{}`
  */
  --my-custom-scoped-css-variable: var(--kui-space-20, #{$kui-space-20});

  margin: var(--my-custom-scoped-css-variable, #{$kui-space-10});
  color: var(--kui-color-text-primary, $kui-color-text-primary);
  font-weight: var(--kui-font-weight-semibold, $kui-font-weight-semibold);
  padding: var(--kui-space-20, $kui-space-20) var(--kui-space-40, $kui-space-40);
}
</style>

Inspecting the example above, you will notice that we fist import the SCSS variables. We then set each style property to the CSS variable, using the SCSS static variable as the fallback.

Important: notice we do not import CSS variables.

When Kongponents are imported and used in a host application, the components will utilize the SCSS fallback values by default since the CSS variables are undefined. This is the normal usage and works great for most applications.

Note: notice how you have to use interpolation when using SCSS variable tokens in custom property values (such as defining CSS variable).

If your application wants to customize some of the properties, it's easy by simply defining the CSS variables you want to override inside of your host application, as shown here:

<style>
// You may scope the variable to `root:` to impact the whole application...
:root {
  --kui-color-text-primary: green;
}

// ...or scope the variable to a specific container to keep the changes isolated
table .my-table-row {
  --kui-color-text-primary: purple;
}
</style>

Now that we have set a value for the CSS variable --kui-color-text-primary in our host application, any instance of this CSS variable in the components will utilize our custom value instead of the default value.

Host applications

Typically, a host application should only utilize the SCSS and/or JavaScript variables to define its styles. Host applications typically do not need to be customized after compile time, meaning there is no reason to use the CSS variables with SCSS variable fallbacks. Here's an example:

<style lang="scss">
// Import SCSS variables
@import "@kong/design-tokens/tokens/scss/variables";

// We directly reference the SCSS variables here which will be replaced with static values during the build
.my-app-custom-class {
  color: $kui-color-text-primary;
  font-weight: $kui-font-weight-semibold;
  padding: $kui-space-20 $kui-space-40;
}
</style>

Kongponents

Kongponents ships its own defineKongponentsTheme helper that validates a theme object against the full typed token surface at authoring time. To use a pre-built design-tokens theme in Kongponents, wrap it with defineKongponentsTheme:

// my-app-theme.ts
import { electricLimeDay } from '@kong/design-tokens/themes'
import { defineKongponentsTheme } from '@kong/kongponents'

export const myTheme = defineKongponentsTheme({
  ...electricLimeDay,           // spread the base theme
  '--kui-button-border-radius-medium': '999px',  // then override specific tokens
})

Register the theme at app startup via the Kongponents plugin:

// main.ts
import { createApp } from 'vue'
import Kongponents from '@kong/kongponents'
import { myTheme } from './my-app-theme'
import App from './App.vue'

createApp(App)
  .use(Kongponents, { theme: myTheme })
  .mount('#app')

Or apply a theme to a specific subtree at runtime using KThemeProvider:

<template>
  <KThemeProvider :theme="myTheme">
    <!-- everything here renders with myTheme active -->
  </KThemeProvider>
</template>

For per-tenant runtime composition (e.g. theme values fetched from an API), use applyTheme from @kong/kongponents:

import { applyTheme } from '@kong/kongponents'
import { electricLimeDay } from '@kong/design-tokens/themes'

// Merge the base theme with tenant-specific overrides, then apply to :root
applyTheme({ ...electricLimeDay, ...tenantOverrides })

Server-Side Rendering (SSR)

If your host application utilizes SSR, you may need to resolve aliases to the package exports.

For example, in a VitePress site, add the following to your vite.config.ts

export default defineConfig({
  resolve: {
    alias: {
      // Explicitly alias the SCSS file since we are overriding the default import below
      '@kong/design-tokens/tokens/scss/variables': path.resolve(__dirname, '../node_modules/@kong/design-tokens/dist/tokens/scss/variables.scss'),
      // Alias `@kong/design-tokens` imports to specifically utilize the esm build
      '@kong/design-tokens': path.resolve(__dirname, '../node_modules/@kong/design-tokens/dist/tokens/js/index.mjs'),
    },
  },
})

Updating Tokens & Local Development

To get started, install the package dependencies from the repo root:

pnpm install

Directory structure

The package is organized around three top-level source directories:

| Directory | Purpose | |-----------|---------| | tokens/source/ | Semantic tokens exported to custom-properties.css, SCSS, and JS. Each token family is its own subdirectory: color/, space/, shadow/, font/, border/, animation/, breakpoint/, letter-spacing/, line-height/, plus the concept-named families method/, status/, navigation/, and icon/ (HTTP methods, status codes, navigation chrome, icons). | | tokens/components/ | Component tokens — name-only override slots for Kongponents components (button/, card/, input/, badge/, …). All $value fields must be "". Included in KUI_THEMEABLE_TOKENS — no CSS, no SCSS/JS values emitted. | | themes/ | Named theme override sets, one directory per theme (themes/<name>/), each holding two co-located files: <name>.theme.json (the token values that activate for [data-kui-theme="<name>"]) and <name>.alias.color.json (that theme's color palette — the internal alias tokens, never exported, that <name>.theme.json's {color.alias.*} references resolve against). Both filenames are required and enforced by the build and tests. themes/_manifest.alias.color.json is the names-only contract every palette must match. |

Token Requirements

• Token keys must be lowercase, snake_case, and defined in normal alphabetical order (rules enforced by the eslint config)

• The category of each token should be its own directory (e.g. tokens/source/color/)

• Each type of token should be a file in the category directory, named {type}.json (e.g. tokens/source/color/background.json)

• If there is only a single type of token within a category, you should name the file index.json (e.g. tokens/source/line-height/index.json)

• Alias tokens (themes/<name>/<name>.alias.color.json) must not be exposed/exported from the package exports

• Tokens at the "root" of their structure must be defined with a key of "_" to allow for nested child tokens.

• Component tokens in tokens/components/ must always have $value: "" — they are name-only slots with no CSS value. A non-empty $value is a build violation caught by the test suite.

  {
    "color": {
      "text": {
        "_": {
          "$description": "Default text color.",
          "$value": "{color.alias.blue.100}"
        },
        "neutral": {
          "_": {
            "$description": "Neutral text color.",
            "$value": "{color.alias.gray.60}"
          },
          "strong": {
            "$description": "Strong neutral text color.",
            "$value": "{color.alias.gray.70}"
          }
        }
      }
    }
  }

  /* Output */
  --kui-color-text: #000933;
  --kui-color-text-neutral: #6c7489;
  --kui-color-text-neutral-strong: #52596e;

Creating a new theme

A new theme is scaffolded directly from the canonical token tree — not copied from an existing theme. pnpm theme:scaffold <name> generates themes/<name>/<name>.theme.json and themes/<name>/<name>.alias.color.json:

• Every semantic token (tokens/source/**) is seeded with its real default {color.alias.*} mapping — a safe, sensible starting point.
• Every component token (tokens/components/**) is seeded as an empty slot ($value: "") for you to fill deliberately — a component token's value is a genuine design decision (e.g. an alert's danger background is a light tint, not the strong semantic danger color) and can't be safely defaulted.
• The palette is seeded from classic-day's real neutral values, so the theme builds and renders immediately, rather than from a placeholder.

The result is exhaustive by construction — it contains exactly KUI_THEMEABLE_TOKENS, with no comparison against any other theme required. (For a semantic-only theme instead — every semantic token, zero component tokens, like classic-day/classic-night — scaffold normally, then delete the component-token entries and add the theme's name to SEMANTIC_ONLY_THEMES in platforms/themes.mjs.)

pnpm theme:scaffold my-brand
# Fill in real palette values (themes/my-brand/my-brand.alias.color.json) and component
# tokens (themes/my-brand/my-brand.theme.json) to taste.
pnpm themes:unfilled my-brand   # reports empty component slots and palette families still
                                # unchanged from the classic-day seed
pnpm build:tokens && pnpm test  # the drift and off-source guards confirm completeness

The build auto-discovers any themes/<name>/<name>.theme.json — no code change needed. A theme directory whose <name>.theme.json is missing is a hard build error (and fails pnpm test), as is an alias-referencing theme with no matching <name>.alias.color.json palette (no silent fallback). See ALIAS-COLOR-MAPPING-GUIDE.md §6, "Adding a future theme".

Keeping every theme in sync as the token set grows. Adding a token to tokens/source/** or tokens/components/** doesn't require hand-editing every theme file — run pnpm themes:sync to add the new token to every theme (semantic tokens get their source default; component tokens get an empty slot to fill), or pnpm themes:unfilled <name> to check what any one theme still needs.

Note — theme-creation skill dependency. The theme-creation skill in packages/skills/theme-creation/ automates this flow end-to-end (scaffolding, matching a source's look, previewing against Kongponents). It calls this package's theme:scaffold / themes:sync / themes:unfilled commands directly rather than duplicating their logic, so renaming or restructuring those commands (scripts/theme-scaffold.mjs, scripts/themes-sync.mjs, scripts/themes-unfilled.mjs) only needs updating in one place — the skill won't silently drift out of sync with them. The relationship runs the other way for previewing: theme:preview (see Previewing a theme) is this package aliasing into the skill's own scripts/preview.mjs, not the reverse — that script is a verification tool owned by the skill.

Previewing a theme

pnpm theme:preview -- <name> [<name>...] [--port 8747] [--kongponents <version|tag>] renders a theme against real @kong/kongponents components (buttons in every state, badges, cards, inputs, radios/switch, multiselect, date picker, tabs, a paginated table, modals/prompts/slideouts, tooltips, alerts, and more) loaded from a CDN — no local install or build. It serves a local HTTP gallery and prints the URL to open:

pnpm build:tokens                              # theme:preview reads dist/themes/<name>.css
pnpm theme:preview -- my-brand
# Preview serving at:  http://localhost:8747/index.html

Pass more than one theme name to compare them side by side in one page — the common case for a day/night pair, since they're usually eyeballed together rather than one at a time:

pnpm theme:preview -- my-brand-day my-brand-night
# renders Original (unthemed) | my-brand-day | my-brand-night as three columns on one page

By default it renders against the latest published @kong/kongponents, which does not yet consume every component token (e.g. button geometry/per-appearance colors) — pass --kongponents <version|tag> (or --kongponents-css <url>/--kongponents-esm <url> for a canary/PR build not on the normal registry path) to preview against the build that actually reads the tokens your theme sets:

pnpm theme:preview -- my-brand --kongponents 9.60.6

theme:preview is a convenience alias for packages/skills/theme-creation/scripts/preview.mjs — the script itself is owned by, and lives in, the theme-creation skill (see that skill's CLAUDE.md), not this package, since it's a verification tool with no build/test contract of its own. pnpm --filter @kong/design-tokens theme:preview -- ... works the same from the repo root.

Theme $description authoring rules

Every token entry in a theme JSON file may carry an optional $description field. When present, it must follow these rules:

• Match the semantic token's description — copy the text from the corresponding token in tokens/source/. Do not invent a different description for the same concept.
• Never reference a CSS value — descriptions must be value-agnostic. The description explains what the token controls, not what value it currently holds.

| ❌ Avoid | ✅ Use instead | |---|---| | "2px border radius." | (omit — scale tokens are self-documenting by name) | | "Background color for containers (white)." | "Default background color for containers." | | "Border color for danger actions or messages (red.60)." | "Border color for danger actions or messages." | | "0px 0px 0px 1px blue.60 inset" | "Primary state inset border shadow." |

When to omit $description entirely: pure scale tokens (--kui-space-*, --kui-border-radius-0 through -50, --kui-border-width-*, --kui-icon-size-*, --kui-line-height-*, --kui-letter-spacing-*) are self-documenting — their token names carry all the meaning. Leave $description off these entries.

Component tokens may appear in theme files with $description. A theme may set any component token (--kui-button-*, --kui-card-*, etc.) to provide per-component customization that diverges from the semantic fallback. Use the same description as the component token's source definition in tokens/components/.

// ✅ Correct — description matches source definition
"kui-button-border-radius-medium": {
  "$description": "Medium button border radius.",
  "$value": "999px"
}

A theme file must define its full token set, not just the tokens it changes. An exhaustive theme must contain exactly KUI_THEMEABLE_TOKENS (every semantic and component token); a semantic-only theme (SEMANTIC_ONLY_THEMES) must contain every semantic token and zero component tokens — nothing may be missing, even if its value is identical to another theme's. The [data-kui-theme] CSS cascade / var() fallback behavior governs runtime behavior for component tokens that are legitimately absent from a semantic-only theme (they fall through to the semantic layer) — it does not mean a theme file itself may omit tokens whose value happens not to differ. pnpm theme:scaffold and pnpm themes:sync handle this for you: every scaffolded or synced theme already contains its full required set.

Development Sandbox

This package includes a Vue sandbox (see the sandbox/ directory) to allow you to experiment with consuming tokens.

To start the sandbox, run from the repo root:

pnpm sandbox:design-tokens

Or from within this package directory:

pnpm sandbox

This command simultaneously starts the Vite dev server and watches both the tokens/ and themes/ directories. Changes to either trigger a rebuild and restart the Vite dev server.

Updating any files within the sandbox itself will also trigger hot module reload as expected.

Lint and fix

Lint package files, and optionally auto-fix detected issues.

# Lint only
pnpm lint

# Lint and fix
pnpm lint:fix

Shared build utilities

Build-time utilities — Style Dictionary transforms, string helpers, and the file-header factory — live in this package's own utilities/ directory and are exported from utilities/index.mjs.

Package-specific build utilities (e.g. transforms or formatters that only apply to @kong/design-tokens) should be added to utilities/ and exported from utilities/index.mjs.

Build for production

Utilize the style-dictionary CLI to build the token assets for production based on the configuration in config.mjs.

From this package directory:

pnpm build

Or from the repo root:

pnpm --filter @kong/design-tokens build

If additional sub-directories (other than dist/tokens) are added to the dist/ directory in config.mjs, you will also need to create a new corresponding entry in the package.json > exports section to allow for importing into the host project without dist/ in the path.

For example, if I want to add a new my-feature folder, I'd update the exports entry as shown here:

"exports": {
  // ... more entries
  "./tokens/*": "./dist/tokens/*",
  "./my-feature/*": "./dist/my-feature/*" // New directory
}

Token Update Workflow

1. Ensure you are on the main branch, then pull down the latest code by running git checkout main && git pull origin main
2. Checkout a new branch for your changes with git checkout -b {type}/{jira-ticket}-{description} — as an example, git checkout feat/khcp-1234-add-color-tokens
3. Add/edit the tokens in the tokens/ or themes/ directory as needed, ensuring to adhere to the Token Requirements
4. Before committing your changes, locally run pnpm lint to ensure you do not have any linting errors. If you have errors, you can try running pnpm lint:fix to resolve
5. Commit your changes, adhering to Conventional Commits. To make this easier, you're encouraged to run pnpm commit from the repo root to help build your commit message
6. Push your branch up to the remote with git push origin {branch-name}
7. Open a pull request and request a review

Committing Changes

This repo uses Conventional Commits.

Commitizen and Commitlint are used to help build and enforce commit messages.

It is highly recommended to use the following command from the repo root in order to create your commits:

pnpm commit

This will trigger the Commitizen interactive prompt for building your commit message.

Enforcing Commit Format

Lefthook is used to manage Git Hooks within the repo.

• A commit-msg hook is automatically setup that enforces commit message standards with commitlint
• A pre-push hook is used that runs eslint before allowing you to push your changes to the repository

Additionally, CI will use commitlint to validate the commits associated with a PR in the Lint and Validate job.

Approvals

• All pull requests require review and approval from authorized team members.
• Automated approvals through workflows are strictly prohibited.
  • There is an exception for automated pull request approvals originating from generated dependency updates that satisfy status checks and other requirements.
• Protected branches require at least one approval from code owners.
• All status checks must pass before a pull request may be merged.

Package Publishing

This package is published automatically via lerna-lite in independent mode. Releases are triggered by conventional commits on main, alpha, and beta branches.