- TypeScript (ESM).
- Prefer strict typing; avoid
any. - Use TypeScript's
strictmode to catch null/undefined errors.
- Strict type checking enabled.
- Use ES modules (
import/export). - All public functions and methods must have explicit return types.
PascalCasefor classes, interfaces, and types.camelCasefor functions, methods, and variables.
- All source files should be lowercase with hyphens (kebab-case). E.g.,
relay-handler.ts. - Test files must be co-located with source files and use the
.test.tssuffix. E.g.,relay-handler.test.ts.
- Use ES module style (
import { x } from './y.js'). - All relative imports must include the
.jsextension to ensure ESM compatibility.
- Tests must explicitly check for expected errors.
- 2-space indentation.
- Semicolons are required.
- Single quotes (
') are preferred over double quotes (").
- Tests must be co-located with source files.
- Use descriptive test names that clearly state what is being tested.
- JSDoc for all public APIs (classes, methods, interfaces, types).
- Inline comments for complex or non-obvious logic only.
- Avoid commenting on obvious things or writing lengthy comments.
- Brief comments (1-2 lines) are preferred to explain "why" rather than "what".
- Keep files concise: Extract helpers instead of creating "V2" copies.
- Use existing patterns for dependency injection via constructor options.
- Prioritize clear ownership boundaries: The goal is to ensure each module answers a single architectural question.
- Modularize around protocol or lifecycle concerns: Modularization should follow logical sub-flows (e.g., event unwrapping, inbound coordination, outbound routing) rather than arbitrary code splitting.
- Aim to keep files under ~700 LOC: This is a heuristic guideline only, not a hard guardrail.
- Split or refactor when it improves clarity or testability.
- The library must be compatible with Node.js version 18 or higher.
- Production SDK code must remain browser-safe unless a module is explicitly server-only.
- Do not use Node-only globals such as
Bufferin non-test source files. Prefer Web Platform APIs such asTextEncoder,TextDecoder,crypto.subtle, and runtime-neutral helpers. - If a server-oriented module needs encoding utilities, use shared runtime-neutral helpers so the file remains safe to bundle unless intentionally documented otherwise.
- Any new shared transport or protocol path must be reviewed for both Node and browser compatibility before merging.
- Use
bunas the package manager and test suite.