Contributing

​

Setting up the framework

git clone https://github.com/86d-store/86d
cd 86d
bun install
86d init

​

The six health gates

bun run generate:modules -- --frozen  # Generated Module registry
bun run typecheck                     # TypeScript
bun run check                         # Biome lint + format
bun run test                          # Unit and integration tests
bun run docker:build                  # Production Store Runtime image
bun run docker:verify                 # Container boot and health smoke

​

Commit messages

type(scope): subject

feat(store): add checkout finalization step
fix(modules): handle empty cart in stripe webhook
docs(guides): add module installation steps
chore(deps): bump turbo to 2.10.9

​

What a good pull request looks like

• One change. A bug fix, or an endpoint, or a Module, or a docs improvement. Not all four.
• Tests that match the change. New endpoint means Vitest tests. UI changes need rendered-state coverage and direct Chrome review. Add Playwright only for a real-browser seam. Bug fixes need a regression test that fails without the fix.
• A description worth reading. What problem this solves, why this approach, what you considered instead, and what it does not cover.
• A Changesets entry for anything affecting a published package. Run bunx changeset and commit the file. CI rejects the pull request without one when one is needed.

​

Coding standards

• No any, @ts-expect-error, @ts-ignore, or biome-ignore. Fix the type or the code underneath.
• No config edits to silence an error. If a rule genuinely does not fit, raise it. Do not route around it in tsconfig.json or biome.json.
• Do not edit UI primitives. Wrap or compose shadcn/ui, Base UI, Radix UI, and React Aria rather than changing their internals.
• Never weaken or delete a passing test to get a change through.
• Biome does the formatting. bun biome check --write src/.

​

Writing a Module

86d module create my-feature
86d module enable my-feature
86d generate
bun test --filter @86d-store/my-feature

• a real schema, with types and relations that mean something
• Storefront and admin endpoints actually implemented, with no TODO bodies
• loading, error, and empty states in every UI component
• Vitest tests on the paths that matter, with fixtures shaped like the real provider response
• for anything talking to an outside API: real HTTP, retries, error mapping, and webhook signature verification
• rendered-state tests for every new screen state
• direct Chrome review at 1280 x 720 and 375 x 667, in light and dark, including focus, overflow, errors, and recovery
• focused Playwright coverage only when the behavior depends on navigation, storage, focus, responsive layout, browser request construction, or another browser boundary

​

Publishing your own Module

1. Build with bun run build so dist/ contains JavaScript and .d.ts (plus copied .mdx assets when needed).
2. Set "private": false and a release version in package.json.
3. Restrict "files" to dist (+ README); map publishConfig.exports to ./dist. Do not publish src or test/tooling files.
4. Replace workspace:* / catalog: with real semver versions.
5. Add accurate package metadata and provenance.
6. Publish: npm publish --access public.

86d module add npm:@your-scope/your-module

​

Documentation

git clone https://github.com/86d-store/docs
cd docs
npm i -g mint
mint dev

• Active voice. “Run the command”, not “the command should be run”.
• Sentence case headings. Defined terms keep their capitals inside one.
• No em dashes. Comma, colon, semicolon, parentheses, or a new sentence.
• Working examples. If you cite a command or an endpoint, paste the exact form and run it first.

​

Releases

​

License

​

Code of conduct

​

Security issues

​

Getting help

• Discussions for design proposals and open questions.
• Issues for bugs and feature requests.

​

Related pages

• Build a custom Module
• Test the Store Runtime
• Versioning and maturity
• Changelog