Repository structure
Development setup
You need Deno to work on this project. There is no separate install step — Deno fetches dependencies on first run.npm install, no build step for running tests.
Running tests
deno test -A). Test files live in packages/sdk/tests/ and alongside source files as *.test.ts.
Building the npm package
The SDK is published to both JSR and npm. The npm build transpiles Deno source to a Node.js-compatible package:Documentation
The docs use Mintlify. To preview docs locally:packages/sdk/docs/ as .mdx files. Navigation is configured in packages/sdk/docs/docs.json.
Code style
- TypeScript everywhere — no plain JavaScript in
lib/orcommunity/. - Immutable patterns — create new objects rather than mutating existing ones.
- Small, focused files — aim for 200–400 lines per file; 800 is the maximum.
- Explicit error handling — never silently swallow errors. Provide typed error classes where useful.
- No hardcoded values — use constants or configuration.
Commit format
Follow Conventional Commits:feat, fix, refactor, docs, test, chore, perf, ci.
Examples:
Pull request process
- Fork the repository and create a branch from
main. - Write tests first — add or update tests in
packages/sdk/tests/before implementing the change. - Run the full test suite with
deno task testfrom the repo root. - Run the linter and formatter with
deno lint && deno fmt. - Open a PR against
mainwith a clear description of what changed and why.
For significant changes (new API surface, breaking changes, new community toolsets), open an issue first to discuss the approach before writing code.
Adding a community toolset
Community toolsets live inpackages/sdk/community/. Each toolset is a directory:
port-pydantic-ai-community-plugins skill for a step-by-step porting guide.