Contributing Guide
Complete guide for contributing to Zero development with setup and workflow.
We welcome contributions to 0.email! This guide will help you get started with contributing to the project, whether you're fixing bugs, adding features, or improving documentation.
Getting Started
Prerequisites
Before contributing, make sure you have the following installed:
Node.js
v18 or higher for runtime environment
pnpm
v8 or higher for package management
Git
Version control system
GitHub Account
For contributing to the repository
Development Setup
1. Fork the Repository
# Click "Fork" on GitHub, then clone your fork
git clone https://github.com/your-username/Zero.git
cd Zero
# Add upstream remote
git remote add upstream https://github.com/Mail-0/Zero.git
2. Install Dependencies
pnpm install
3. Set Up Environment
# Start database
pnpm docker:db:up
# Setup environment variables
pnpm nizzy env
pnpm nizzy sync
# Initialize database
pnpm db:push
4. Start Development Server
pnpm dev
The development server will be available at http://localhost:3000
Development Workflow
Follow these steps for contributing code changes:
1. Create a New Branch
Always create a new branch for your changes:
git checkout -b feature/your-feature-name
# or
git checkout -b fix/your-bug-fix
Remember to make staging
branch as your base branch, not main
.
2. Make Your Changes
- Write clean, maintainable code
- Follow our coding standards
- Add/update tests as needed
- Update documentation if required
3. Test Your Changes
- Make sure the app runs without errors
- Test your feature thoroughly
4. Commit Your Changes
Use clear, descriptive commit messages following Conventional Commits:
git commit -m "feat: add new email threading feature
Implements #123"
5. Stay Updated
Keep your fork in sync with the main repository:
git fetch upstream
git merge upstream/staging
6. Push to Your Fork
git push origin your-branch-name
7. Submit a Pull Request
- Go to your fork on GitHub and click "New Pull Request"
- Make sure to target the
staging
branch - Fill out the PR template completely
- Link any relevant issues
- Add screenshots for UI changes
Database Management
Zero uses PostgreSQL with Drizzle ORM for database operations.
Database Structure
The database schema is defined in the server application directory.
Common Database Tasks
# Apply schema changes to development database
pnpm db:push
# Create migration files after schema changes
pnpm db:generate
# Apply migrations (for production)
pnpm db:migrate
# View and edit data with Drizzle Studio
pnpm db:studio
Database Connection
For local development, ensure your .env
file contains:
DATABASE_URL="postgresql://postgres:postgres@localhost:5432/zerodotemail"
Troubleshooting
- Connection Issues: Make sure Docker is running (
pnpm docker:db:up
) - Schema Errors: Check your schema files for syntax errors
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Types
Examples
git commit -m "feat(mail): add email search functionality"
git commit -m "fix(auth): resolve login redirect issue"
git commit -m "docs: update API documentation"
git commit -m "test(mail): add email composer tests"
Code Style and Standards
Consistent code style ensures maintainability and readability across the entire codebase.
TypeScript Guidelines
We use TypeScript for type safety and better developer experience. Follow these guidelines for consistent code.
// Use explicit types when helpful
interface EmailListProps {
emails: Email[]
onSelect: (email: Email) => void
className?: string
}
// Use type guards for runtime checks
function isEmail(value: unknown): value is Email {
return typeof value === 'object' &&
value !== null &&
'id' in value &&
'subject' in value
}
// Prefer const assertions for immutable data
const EMAIL_STATUSES = ['sent', 'draft', 'failed'] as const
type EmailStatus = typeof EMAIL_STATUSES[number]
// Use generics for reusable components
interface ApiResponse<T> {
success: boolean
data: T
error?: string
}
React Component Guidelines
Follow these patterns for consistent, performant React components.
// Use functional components with hooks
const EmailList = memo<EmailListProps>(({ emails, onSelect, className }) => {
// State and effects at the top
const [selectedId, setSelectedId] = useState<string | null>(null)
// Memoized values
const sortedEmails = useMemo(() =>
emails.sort((a, b) => new Date(b.createdAt).getTime() - new Date(a.createdAt).getTime()),
[emails]
)
// Event handlers
const handleSelect = useCallback((email: Email) => {
setSelectedId(email.id)
onSelect(email)
}, [onSelect])
// Early returns for loading/error states
if (emails.length === 0) {
return <EmptyState />
}
// Main render
return (
<div className={cn("email-list", className)}>
{sortedEmails.map(email => (
<EmailItem
key={email.id}
email={email}
isSelected={selectedId === email.id}
onSelect={handleSelect}
/>
))}
</div>
)
})
EmailList.displayName = 'EmailList'
CSS/Styling Guidelines
We use Tailwind CSS for utility-first styling with consistent design patterns.
/* Use Tailwind utility classes */
.email-item {
@apply flex items-center gap-3 p-3 border-b border-border
cursor-pointer hover:bg-accent/50 transition-colors;
}
.email-item--selected {
@apply bg-accent;
}
/* Avoid magic numbers, use design tokens */
.email-avatar {
@apply h-8 w-8; /* Instead of h-[32px] w-[32px] */
}
Component Styling Patterns
- Use
cn()
utility for conditional classes - Prefer Tailwind utilities over custom CSS
- Use CSS variables for theming
- Keep responsive design in mind
Styling Best Practices
- Use consistent spacing scale (4px, 8px, 12px, 16px, etc.)
- Follow color palette from design system
- Use semantic color names (primary, secondary, accent)
- Maintain consistent typography scale
Internationalization (i18n)
0.email supports multiple languages through our internationalization system, making the application accessible to users worldwide.
Adding Translations for New Features
When implementing new features, follow these guidelines:
1. Add English Source Strings
- Place all user-facing text in
apps/mail/locales/en.json
- Organize strings according to the existing structure
- Use descriptive, hierarchical keys that identify the feature and context
{
"pages": {
"settings": {
"connections": {
"disconnectSuccess": "Account disconnected successfully"
}
}
}
}
2. Follow i18n Formatting Standards
- Variables:
{variableName}
- Pluralization:
{count, plural, =0 {items} one {item} other {items}}
- Avoid string concatenation to ensure proper translation
3. Quality Checklist
- All visible UI text is externalized (not hardcoded)
- Strings are organized in logical sections
- Context is clear for translators
- The feature works properly with the default language
Testing
Comprehensive testing ensures code quality and prevents regressions. We use multiple testing strategies.
Testing Strategy
Testing framework is currently being set up. Check back for updates on testing guidelines and commands.
Unit Tests
Individual functions and components (Coming Soon)
Integration Tests
Component interactions and workflows (Coming Soon)
E2E Tests
Full user workflows and scenarios (Coming Soon)
API Tests
Backend endpoint testing (Coming Soon)
Testing Commands (Coming Soon)
# These commands will be available once testing is set up:
pnpm test # Run all tests
pnpm test:watch # Run tests in watch mode
pnpm test:coverage # Run tests with coverage
pnpm test:e2e # Run E2E tests
Writing Tests (Coming Soon)
Testing framework is currently being set up. Guidelines for writing tests will be provided once the testing infrastructure is implemented.
Documentation
Writing Documentation
- Use clear, concise language
- Include code examples
- Add screenshots for UI features
- Test all code examples
- Follow the existing structure
Documentation Structure
Adding New Documentation
- Create
.mdx
file in appropriate directory - Add frontmatter with title and description
- Include relevant code examples
- Add to navigation if needed
- Test all examples
Pull Request Process
Before Submitting
-
Run Tests
Terminal pnpm test pnpm test:e2e pnpm lint pnpm type-check
-
Check Build
Terminal pnpm build
-
Update Documentation
- Update relevant docs
- Add JSDoc comments
- Update CHANGELOG.md
-
Test Manually
- Test your changes in development
- Verify existing functionality still works
- Test in different browsers
PR Template
When creating a pull request, include:
## Description
Brief description of what this PR does.
## Type of Change
- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that causes existing functionality to not work as expected)
- [ ] Documentation update
## Testing
- [ ] Manual testing completed
- [ ] Code formatting passes (pnpm format)
- [ ] Linting passes (pnpm lint)
## Screenshots
Include screenshots for UI changes.
## Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Code is commented where necessary
- [ ] Documentation updated
- [ ] Tests added/updated
- [ ] No new console errors/warnings
Review Process
-
Automated Checks
- Tests must pass
- Linting must pass
- Build must succeed
- Type checking must pass
-
Code Review
- At least one maintainer review
- Address all feedback
- Ensure code quality standards
-
Final Testing
- Manual testing by reviewer
- Compatibility testing
- Performance impact assessment
Issue Guidelines
Reporting Bugs
Use the bug report template:
**Bug Description**
A clear description of the bug.
**To Reproduce**
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
**Expected Behavior**
What you expected to happen.
**Screenshots**
If applicable, add screenshots.
**Environment**
- OS: [e.g. macOS, Windows, Linux]
- Browser: [e.g. Chrome, Firefox, Safari]
- Version: [e.g. 1.0.0]
**Additional Context**
Any other context about the problem.
Feature Requests
Use the feature request template:
**Feature Description**
A clear description of the feature you'd like to see.
**Problem Statement**
What problem does this feature solve?
**Proposed Solution**
How would you like this feature to work?
**Alternatives Considered**
Any alternative solutions you've considered.
**Additional Context**
Any other context, screenshots, or examples.
Development Environment
Recommended Tools
- Code Editor: VS Code with recommended extensions
- Browser: Chrome with React DevTools
- Database: TablePlus or similar for database management
- API Testing: Postman or Insomnia
- Git GUI: GitHub Desktop or SourceTree (optional)
VS Code Extensions
{
"recommendations": [
"bradlc.vscode-tailwindcss",
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint",
"ms-vscode.vscode-typescript-next",
"ms-playwright.playwright",
"ms-vscode.vscode-json"
]
}
Environment Variables
# Development environment
NODE_ENV=development
PORT=3000
APP_URL=http://localhost:3000
# Debug settings
DEBUG=zero:*
LOG_LEVEL=debug
ENABLE_QUERY_LOGGING=true
# Test database
TEST_DATABASE_URL=sqlite:./test.db
Architecture Decisions
Making Changes
For significant architectural changes:
-
Create RFC (Request for Comments)
- Document in
docs/rfcs/
- Explain problem and proposed solution
- Get community feedback
- Document in
-
Discuss in Issues
- Create GitHub issue for discussion
- Tag relevant maintainers
- Allow time for feedback
-
Prototype First
- Create proof of concept
- Test performance impact
- Validate approach
Current Architecture
See Architecture Overview for detailed information about:
- Component structure
- State management patterns
- API design principles
- Database schema design
- Performance considerations
Community Guidelines
Code of Conduct
We follow the Contributor Covenant:
- Be respectful - Treat everyone with respect
- Be inclusive - Welcome newcomers and diverse perspectives
- Be patient - Help others learn and grow
- Be collaborative - Work together towards common goals
Communication Channels
- GitHub Issues - Bug reports and feature requests
- GitHub Discussions - General questions and ideas
- Pull Requests - Code contributions and reviews
- Discord - Real-time chat (community server)
Getting Help
If you need help:
- Check existing documentation
- Search GitHub issues
- Ask in GitHub Discussions
- Join Discord community
- Tag maintainers if urgent
Recognition
Contributors
All contributors are recognized in:
CONTRIBUTORS.md
file- GitHub contributors page
- Release notes for significant contributions
- Annual contributor highlights
Types of Contributions
We value all types of contributions:
- Code - Features, bug fixes, optimizations
- Documentation - Guides, API docs, examples
- Testing - Writing tests, finding bugs
- Design - UI/UX improvements, icons, graphics
- Community - Helping others, moderation
- Feedback - Bug reports, feature ideas, reviews
Looking for contributing to Zero Email ! 🎉