Thank you for your interest in contributing to Padrone! This guide will help you get started.
- Bun (v1.0 or later)
- Node.js 18+ (for compatibility testing)
- Git
-
Fork and clone the repository:
git clone https://github.com/YOUR_USERNAME/padrone.git cd padrone -
Install dependencies:
bun install
-
Verify your setup:
bun run checks
padrone/
├── packages/padrone/ # Main library
│ ├── src/ # Source code
│ └── tests/ # Tests
├── docs/ # Documentation site
├── examples/ # Example applications
└── scripts/ # Build scripts
bun run test # Run tests
bun run check # Lint and format check
bun run typecheck # Type checking
bun run checks # All of the aboveThis project uses Biome for linting and formatting. Key points:
- Indent: 2 spaces
- Quotes: Single quotes
- Line width: 140 characters
Important: Zod imports must use namespace syntax:
import * as z from 'zod/v4'; // CorrectFor detailed style guidelines, see AGENTS.md.
# All tests
bun run test
# Single file
bun run test packages/padrone/tests/cli.test.ts
# By pattern
bun run test --test-name-pattern "should parse"git checkout -b feature/your-feature-name- Write clear, focused commits
- Add tests for new functionality
- Update documentation if needed
When your change should be noted in the changelog, create a changeset:
bun changesetFollow the prompts to:
- Select the
padronepackage - Choose the version bump type:
- patch: Bug fixes, docs, internal changes
- minor: New features, non-breaking enhancements
- major: Breaking changes
- Write a brief summary of your change
This creates a file in .changeset/ that will be included in the next release's changelog.
When to skip changesets:
- CI/tooling changes only
- Test-only changes
- Documentation typos
Before committing, ensure all checks pass:
bun run checksThe pre-commit hook will automatically run Biome on staged files.
- Push your branch to your fork
- Open a PR against
main - Fill out the PR template
- Wait for CI checks and review
- Keep PRs focused on a single change
- Write a clear description of what and why
- Link related issues
- Respond to review feedback promptly
To release a new version, merge the release PR created by the Changesets. This will trigger the release process, which includes:
- Bumping the version based on changesets
- Generating a changelog
- Publishing to npm
- Search existing issues before creating a new one
- Use issue templates when available
- Provide reproduction steps for bugs
- Include version information
- Open a Discussion for questions
- Check the documentation
By contributing, you agree that your contributions will be licensed under the MIT License.