Contributing

We welcome contributions from the community. The full contribution guidelines live in the CONTRIBUTING.md file at the repository root. This page provides a quick overview.

Quick Start

1. Fork the repository on GitHub

2. Clone your fork and install dependencies:

   git clone https://github.com/your-username/nestjs-jetstream.git
   cd nestjs-jetstream
   pnpm install

3. Create a branch for your change:

   git checkout -b feat/your-feature-name

4. Make your changes, write tests, and verify everything passes:

   pnpm lint
   pnpm test

5. Push and open a Pull Request

Prerequisites

• Node.js >= 20.0.0
• pnpm 10.x or higher
• Docker (integration tests use Testcontainers to start NATS automatically)

Development Commands

Command	Description
pnpm build	Build the library (tsup, dual CJS/ESM)
pnpm build:watch	Build in watch mode
pnpm lint	Check for linting issues
pnpm lint:fix	Auto-fix linting issues
pnpm test	Run all tests
pnpm test:cov	Run tests with coverage
pnpm docs:dev	Start Docusaurus dev server
pnpm docs:build	Build the documentation site
pnpm docs:generate	Regenerate TypeDoc API reference (not pnpm docs — conflicts with npm built-in)

See Testing for detailed test conventions and setup.

Commit Message Format

The project uses Conventional Commits with Release Please for automated releases. Your commit messages determine how the changelog and version bumps are generated.

Prefix	Purpose	Version Bump
feat:	New feature	Minor
fix:	Bug fix	Patch
docs:	Documentation	None
refactor:	Code refactoring	None
test:	Adding/updating tests	None
chore:	Maintenance	None

Examples:

feat: add support for custom stream configuration
fix(strategy): remove private logger that shadows Server base class
docs: update module configuration examples

tip

Use a scope in parentheses (e.g., feat(client):, fix(strategy):) to indicate the area of the codebase affected. This shows up in the generated changelog.

Pull Request Guidelines

• Ensure the build passes (pnpm build)
• All linting checks must pass (pnpm lint)
• All existing tests must pass, and new code should include tests
• Use clear, descriptive PR titles — they become changelog entries via Release Please
• Keep PRs focused on a single concern

Coding Standards

• TypeScript for all code
• JSDoc comments on all public APIs
• Follow existing code style (enforced by ESLint + Prettier)
• See Testing for test conventions (sut naming, createMock<T>(), Given-When-Then, etc.)

License

By contributing, you agree that your contributions will be licensed under the MIT License.