Skip to main content

Contributing

Set up the repo, run the docs, and make changes that are ready to review.

Contributions are welcome when they keep the library easier to use, test, and maintain.

Set up the repository

The canonical contribution policy is CONTRIBUTING.md. From the repository root:

bash
corepack enable
pnpm install

Start the playground or docs app:

bash
pnpm dev:playground
pnpm dev:docs

The playground is the fastest place to verify interaction changes. The docs app uses the workspace packages, so examples exercise the same code consumers install.

Run the checks

Run the narrowest relevant check while you work, then the repository gate before handoff:

bash
pnpm verify

Use pnpm test:e2e for browser interaction or screenshot changes. Maintainers use pnpm release:verify only on a release candidate.

Where docs live

Docs content lives in docs/content.

FolderPurpose
1.evaluateProduct fit and architecture orientation.
2.start-buildingInstallation and first working board.
3.understand-the-systemState, commands, coordinates, and data.
4.build-featuresTask-focused feature guides.
5.solutionsComplete application examples.
6.referenceMaintained public API contracts.
7.projectContribution, support, and security.

Documentation standards

Write each page for one reader and one job. A quickstart should not become a reference page, and a reference page should not become a tutorial.

Before shipping docs, check:

  • The first paragraph says what the page helps the reader do or understand.
  • Examples include imports and setup when needed.
  • Claims about defaults, fields, commands, and behavior match source or tests.
  • Links describe the destination.
  • The page ends with a useful next step.

When code needs docs

Update docs when a change affects:

  • exported package APIs
  • node, edge, selection, camera, or import/export behavior
  • Nuxt module options or auto-imports
  • default UI behavior
  • migration steps for existing users
  • setup commands or package names

For publishable package changes, add a changeset:

bash
pnpm changeset

Pull request shape

A reviewable change has a narrow scope, tests for changed behavior, and docs for user-visible changes.

Include screenshots or short recordings for visual interaction changes. For API docs, include the source change and matching reference update together.

Documentation voice

Write in a calm, direct, technically honest voice. Lead with the answer. Name the package that owns a capability. Explain non-obvious constraints through decision, reason, benefit, cost, and consequence.

Use product-direct writing for evaluation, principle-led writing for concepts, task-first writing for guides, contract-style writing for reference, and neutral analytical writing for comparisons.

Do not hide required facts inside a demo, tab, or accordion. Every interactive lab needs a textual objective, expected result, invariant, and relevant consumer code.