Thanks for your interest in @jonmatum/next-shell. This document covers the setup and the conventions you need to know.
- Node.js 22 (see
.nvmrc) - pnpm 10+
pnpm install| Command | What it does |
|---|---|
pnpm build |
Build all packages via tsup |
pnpm dev |
Watch-build all packages |
pnpm lint |
Run ESLint across the repo |
pnpm format |
Format everything with Prettier |
pnpm format:check |
Verify formatting (used in CI) |
pnpm typecheck |
Run tsc --noEmit across packages |
pnpm test |
Run Vitest once |
pnpm test:watch |
Run Vitest in watch mode |
A pre-commit hook runs lint-staged — it will fix fixable issues automatically.
The single most important rule in this repo is: no raw color values in component source.
This is enforced by the custom next-shell/no-raw-colors ESLint rule:
- No hex literals (
#fff,#abcdef, ...) - No raw CSS color functions (
rgb(),hsl(),oklch(), ...) - No Tailwind palette utilities (
bg-red-500,text-slate-700,bg-white,bg-black, ...)
Use semantic tokens instead: bg-background, text-foreground, border-border, bg-primary, text-primary-foreground, bg-destructive, etc.
Token definition files (anything under src/tokens/ or matching tokens.css) are exempt — those are where the mapping to real colors lives.
We use Conventional Commits:
feat(layout): add Sidebar floating variant
fix(primitives): correct tooltip positioning in RTL
chore(ci): cache pnpm store
- Target
main - Keep PRs focused on a single issue
- Include tests for behavior changes
- Fill out the PR template
Any change that falls into the categories below is considered a breaking change:
- Token renames or removals — changes to
tokens.css,preset.css, or thecolorTokensarray insrc/tokens/index.ts - Removed exports — a named export dropped from any public subpath barrel
- Changed component props — required prop added, prop type narrowed, prop renamed or removed
- CSS class / data-attribute changes —
data-themeattribute renamed, Tailwind utility class prefix changed - Peer dependency bumps — minimum React, Next.js, or Tailwind version increased
- Subpath removals — a
package.json#exportsentry removed or path changed
When introducing a breaking change:
- Add a new version section to
packages/next-shell/MIGRATION.mdfollowing the template at the top of that file. - Include before/after code snippets and step-by-step migration instructions.
- Mention the breaking change prominently in the PR description.
- Update the docs migration page at
apps/docs/content/docs/migration/index.mdx.
Releases are automated via Changesets (lands in Phase 10). Don't publish manually.