Skip to content

Latest commit

 

History

History
66 lines (43 loc) · 2.86 KB

File metadata and controls

66 lines (43 loc) · 2.86 KB

Contributing to Gamification UI Kit by Trophy

Thank you for helping improve Gamification UI Kit by Trophy. This document explains how to set up the repo locally, run the site and tooling, and what we look for in contributions.

Prerequisites

  • Node.js 18 or later (see the README)

  • pnpm 9 — the repo pins the version in packageManager. Enable it with Corepack:

    corepack enable

Getting started

From the repository root:

pnpm install
pnpm dev

pnpm dev runs the Turborepo dev graph. The docs and component showcase live in the www app (Next.js on port 3000 by default).

Other useful root scripts:

Command Purpose
pnpm build Production build across workspaces
pnpm check Lint, typecheck, and Prettier check (good pre-PR sanity pass)
pnpm lint / pnpm lint:fix ESLint
pnpm typecheck TypeScript (tsc --noEmit)
pnpm format:check / pnpm format:write Prettier

Working on components and the registry

Registry sources live under apps/www/registry/. The manifest is apps/www/registry.json; the official shadcn build command emits install payloads to apps/www/public/r/.

When you change registry sources or registry.json, rebuild from the repository root:

pnpm registry:build

That cleans public/r, runs shadcn build, generates all.json for bulk install, then applies formatting. Production builds also run this via prebuild in the www app.

Adding a gamification component:

  1. Add the source file under apps/www/registry/trophy/ui/.
  2. Add an entry to apps/www/registry.json with title, description, dependencies, and registryDependencies (use button for shadcn's Button primitive, not a Trophy catalog item).
  3. Add MDX docs under apps/www/content/docs/components/.
  4. Run pnpm registry:build and commit the updated public/r/* artifacts.

Documentation and examples for components typically live under apps/www/content/docs/ (MDX) and apps/www/components/ as needed. Follow existing patterns for new components or doc pages.

Pull requests

  • Scope: Keep changes focused on one concern when possible (easier review and safer merges).
  • Quality: Run pnpm check (or at least lint, typecheck, and format) before you open a PR.
  • Describe the change: In the PR description, briefly note what changed and why, especially for user-visible or registry-facing updates.

If you are unsure whether an idea fits the project, open an issue or draft PR and we can align on approach before you invest too much time.

License

By contributing, you agree that your contributions will be licensed under the same terms as the project (see LICENSE).