Thank you for your interest in contributing to Pipeit! This document provides guidelines for contributing to the project.
-
Fork the repository
-
Clone your fork
git clone https://github.com/your-username/pipeit.git cd pipeit -
Install dependencies
pnpm install
-
Create a branch
git checkout -b feature/your-feature-name
This is a monorepo managed with Turbo and pnpm workspaces:
packages/core/- Main transaction builder with execution strategies, Flow API, and Kit integrationpackages/actions/- InstructionPlan factories for DeFi (Titan, Metis)packages/fastlane/- Native Rust QUIC client for direct TPU submission (NAPI)examples/next-js/- Next.js example application demonstrating usage
- Node.js >= 20.18.0
- pnpm >= 10
- Rust (for fastlane package development)
- Use TypeScript for all new code
- Follow the existing code style (Prettier + ESLint)
- Use functional programming patterns; avoid classes
- Prefer named exports for components
- Write meaningful commit messages following conventional commits
- Use strict TypeScript configuration
- Prefer interfaces over types
- Avoid enums; use maps instead
- Use descriptive variable names with auxiliary verbs (e.g.,
isLoading,hasError) - Follow the existing type patterns from
@solana/kit
- Add tests for new functionality
- Ensure all tests pass:
pnpm test - Maintain or improve code coverage
- Tests are located in
__tests__/directories within each package
# Format code (if configured)
pnpm run format
# Lint code
pnpm lint
# Type check
pnpm typecheck
# Build all packages
pnpm build
# Run tests
pnpm test- Clear Description: Explain what changes you made and why
- Link Issues: Reference any related issues
- Small PRs: Keep changes focused and atomic
- Tests: Include tests for new functionality
- Documentation: Update README/docs if needed
- Breaking Changes: Clearly mark breaking changes and update version numbers if needed
- Follow Solana best practices for transaction building
- Ensure compatibility with
@solana/kitpatterns - Add comprehensive error handling with proper error types
- Document new execution strategies or features
- Test on devnet before mainnet considerations
- Build Kit-compatible InstructionPlans
- Follow existing Titan/Metis patterns for new integrations
- Document quote/route/plan building pipeline
- Consider API rate limits and error handling
- Rust code follows standard Rust conventions
- Ensure NAPI bindings are properly typed
- Test QUIC connections on devnet
- Document platform-specific requirements
- Update
Cargo.tomlversion when making changes
Include:
- Clear description of the issue
- Steps to reproduce
- Expected vs actual behavior
- Environment details (Node.js version, OS, pnpm version)
- Relevant logs or error messages
- Package version (
@pipeit/core,@pipeit/actions, etc.) - Solana network (mainnet/devnet/testnet)
- Check existing issues first
- Provide clear use case and requirements
- Consider impact on all packages
- Think about backward compatibility
- Consider execution strategy implications (Jito, TPU, parallel)
- All PRs require at least one approval
- CI must pass (lint, typecheck, build, test)
- Code should follow project conventions
- Documentation should be updated for user-facing changes
By contributing, you agree that your contributions will be licensed under the MIT License.
- Open an issue for questions
- Check existing documentation in README.md and package READMEs
- Review
@solana/kitdocumentation for Solana patterns - Check examples in
examples/next-js/for usage patterns
# Build a specific package
cd packages/core
pnpm build
# Run tests for a specific package
cd packages/core
pnpm test
# Watch mode for development
cd packages/core
pnpm devWhen working on execution strategies (Jito, TPU, parallel), test with:
- Devnet for safe testing
- Multiple RPC endpoints
- Different network conditions
- Error scenarios (network failures, timeouts)
cd packages/fastlane
# Build native bindings
pnpm build:native
# Run tests
pnpm test
# Check Rust code
cargo check
cargo clippy