my-kit

The design system for React SPAs — the whole design layer as one direct dependency.

The kit owns the complete component surface, the app-shell (chrome + page-header/tab system), the theme (ThemeProvider / useTheme / BUILT_IN_THEMES), the icons↔emojis seam, the i18n core seam, the page templates, and the shared size + breakpoint scales — all built on Radix + class-variance-authority + mrs--prefixed CSS rendered against the shared --color-* theme tokens (from the framework-neutral themes package). It carries no app wiring — providers, the auth seam, and the i18n provider wiring live in my-shell, the app-wiring scaffold.

Modules (sub-path exports)

| Import | What | |---|---| | @kesteinbakk/my-kit | design size + breakpoint scales | | @kesteinbakk/my-kit/components | the complete component surface (+ …/components/styles.css) | | @kesteinbakk/my-kit/app-shell | the router-coupled chrome + page-header/tab system (+ …/app-shell/styles.css) | | @kesteinbakk/my-kit/theme | ThemeProvider / useTheme / BUILT_IN_THEMES | | @kesteinbakk/my-kit/icons | the icons↔emojis display-mode seam | | @kesteinbakk/my-kit/i18n | the t() core seam + bundled mrs.* chrome catalog | | @kesteinbakk/my-kit/templates | the four page-frame templates (focus · card-stack · content · media) | | @kesteinbakk/my-kit/styles.css | the token contract + themed baseline + the five .theme-* palettes |

@tanstack/react-router is an optional peer needed only by ./app-shell — every other sub-path is router-free, so a visual-only consumer installs no router.

Consuming it

Install from the public npm registry and depend on it directly:

pnpm add @kesteinbakk/my-kit

It is not consumed through my-shell — the shell is an unpublished copy-me scaffold, not a package, so there is nothing to depend on. my-shell still re-exports the kit's modules at its own paths for consumers not yet retrofitted.

The kit is self-sufficient — @kesteinbakk/my-kit alone gives you the whole design layer. Two imports and you are themed:

import '@kesteinbakk/my-kit/styles.css'   // token contract + baseline + the five palettes
import { ThemeProvider } from '@kesteinbakk/my-kit/theme'

…/styles.css carries the .theme-<name>-{light,dark} classes that …/theme applies, so the provider and the palettes it needs ship together. A consumer needs no themes dependency — see Palettes below.

Palettes — vendored, so you never take a themes git-dep

The --color-* token contract and the palettes are authored in the shared, framework-neutral themes package (one source of truth shared with the SolidJS foundation) and vendored into this repo's committed src/themes/*.css. src/index.css imports those copies relatively, so the palettes ship inside the published package.

That is deliberate: vendoring makes kit + palettes one versioned unit at the published version, so the two can never drift into an incompatible pair, and a consumer's install stays a single registry dependency with no second repo to resolve or authenticate to. themes is therefore a devDependency here (the pin records which themes the release vendors) and never reaches a consumer.

Never edit src/themes/*.css by hand — they are generated. Edit colours in ~/Developer/themes, then:

pnpm sync:themes     # re-vendor from the sibling ../themes checkout

The dev-loop watcher (pnpm build:lib:watch) mirrors ../themes → src/themes/ on every save, and a pre-commit guard keeps the committed copies in lockstep.

Distribution

Published to the public npm registry as @kesteinbakk/my-kit. Consumers take an ordinary semver range ("@kesteinbakk/my-kit": "^0.3.0") and pin the exact resolution in their lockfile — one immutable spec on every branch, no credentials, no per-consumer install machinery.

dist/ (JS + types) is built at publish time by prepublishOnly (rm -rf dist && pnpm build:lib) and ships only inside the npm tarball. It is gitignored, never committed. Authored CSS ships straight from src/ (the src/**/*.css files glob) — build:lib emits JS + .d.ts only, so a CSS export is never affected by a dist/ rebuild.

To ship an update: bump the version, pnpm publish, then push + tag vX.Y.Z. Consumers pick it up on reinstall within their range, or by widening the range for a new minor.

Two pre-commit guards remain (pnpm setup:hooks to enable), and both fail closed — if a guard cannot verify what it protects, it blocks the commit rather than warning and passing:

• the committed-link guard rejects a link:/file: specifier in a staged package.json (a dev-loop-only redirect that breaks every other clone and all CI installs), and
• the vendored-themes guard re-vendors src/themes/ from the sibling ../themes checkout whenever the themes wiring, the vendored files, or the pin are staged, so the shipped palette CSS can never drift.

Each message names the fix. git commit --no-verify remains the deliberate bypass, and you own the release if you use it.

The dev-loop watcher (pnpm build:lib:watch, rk:watch under dev start) still rebuilds dist/ on every save so a link:-wired consumer hot-reloads.