Contributing to DBX

Thank you for your interest in contributing to DBX! This guide will help you get started with contributing to the project.

Getting Started

1. Fork the Repository

Go to https://github.com/effortlesslabs/dbx
Click the "Fork" button in the top right
Clone your forked repository

git clone https://github.com/YOUR_USERNAME/dbx.git
cd dbx

2. Set Up Development Environment

Follow the Development Setup Guide to get your environment ready.

3. Create a Branch

git checkout -b feature/your-feature-name
# or
git checkout -b fix/your-bug-fix

Development Guidelines

Code Style

Rust Code

Follow the Rust Style Guide
Use cargo fmt to format code
Use cargo clippy to check for common issues

# Format code
cargo fmt
 
# Run clippy
cargo clippy -- -D warnings

TypeScript Code

Follow the TypeScript Style Guide
Use Prettier for formatting
Use ESLint for linting

cd bindings/redis_ts
npm run format
npm run lint

Testing

Always write tests for your changes:

Rust Tests

# Run all tests
cargo test
 
# Run specific test
cargo test test_name
 
# Run with output
cargo test -- --nocapture

TypeScript Tests

cd bindings/redis_ts
npm test

Integration Tests

# Run full integration tests
./scripts/test-with-server.sh
 
# Run simple tests
./scripts/test-simple.sh

Documentation

Update documentation for any API changes
Add examples for new features
Keep the README up to date

Types of Contributions

Bug Reports

When reporting bugs, please include:

Clear description of the bug
Steps to reproduce
Expected behavior
Actual behavior
Environment details (OS, Rust version, etc.)
Minimal reproduction case (if possible)

Feature Requests

When requesting features, please include:

Clear description of the feature
Use case and motivation
Proposed implementation (if you have ideas)
Alternative solutions you've considered

Code Contributions

Small Changes

For small changes (typos, documentation, etc.):

Make your changes
Run tests to ensure nothing breaks
Submit a pull request

Larger Changes

For larger changes:

Open an issue first to discuss the change
Create a design document for complex features
Implement incrementally with multiple PRs if needed
Add comprehensive tests
Update documentation

Pull Request Process

Before Submitting

Ensure tests pass

cargo test
cd bindings/redis_ts && npm test && cd ../..
./scripts/test-with-server.sh

Check code style

cargo fmt
cargo clippy -- -D warnings
cd bindings/redis_ts && npm run lint && cd ../..

Update documentation
- Update relevant docs
- Add examples if needed
- Update README if necessary

Pull Request Template

Use this template for your PR:

## Description
 
Brief description of the changes.
 
## Type of Change
 
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
 
## Testing
 
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] TypeScript tests pass
- [ ] Manual testing completed
 
## Checklist
 
- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes

Review Process

Automated checks must pass
Code review by maintainers
Approval from at least one maintainer
Merge by maintainers

Release Process

Versioning

We follow Semantic Versioning:

MAJOR version for incompatible API changes
MINOR version for backwards-compatible functionality
PATCH version for backwards-compatible bug fixes

Publishing

Releases are published using our automated scripts:

# Full release (Docker + NPM)
./scripts/publish-release.sh --version 1.0.0
 
# Docker only
./scripts/publish-docker.sh --tag 1.0.0 --push