LogoZero

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

Fork the Repository
Install Dependencies
Set Up Environment
Run Database Migrations
Start Development Server
Verify Setup

1. Fork the Repository

Clone Your Fork
# 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

Install Dependencies
pnpm install

3. Set Up Environment

Environment Setup
# Start database
pnpm docker:db:up

# Setup environment variables
pnpm nizzy env
pnpm nizzy sync

# Initialize database
pnpm db:push

4. Start Development Server

Start Development
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:

Create Branch
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:

Commit Example
git commit -m "feat: add new email threading feature

Implements #123"

5. Stay Updated

Keep your fork in sync with the main repository:

Sync Fork
git fetch upstream
git merge upstream/staging

6. Push to Your Fork

Push Changes
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

Database Operations
# 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
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
Commit Message Format
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Types

Examples

Commit Message 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.

TypeScript Best Practices
// 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.

React Component Example
// 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.

Tailwind Best Practices
  /* 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
Translation Example
{
  "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)

Testing Commands (Not Yet Available)
# 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

index.mdx
architecture.mdx
MCP.mdx
deployment.mdx
contributing.mdx

Adding New Documentation

  1. Create .mdx file in appropriate directory
  2. Add frontmatter with title and description
  3. Include relevant code examples
  4. Add to navigation if needed
  5. Test all examples

Pull Request Process

Before Submitting

  1. Run Tests

    Terminal
    pnpm test
    pnpm test:e2e
    pnpm lint
    pnpm type-check
  2. Check Build

    Terminal
    pnpm build
  3. Update Documentation

    • Update relevant docs
    • Add JSDoc comments
    • Update CHANGELOG.md
  4. Test Manually

    • Test your changes in development
    • Verify existing functionality still works
    • Test in different browsers

PR Template

When creating a pull request, include:

Markdown
## 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

  1. Automated Checks

    • Tests must pass
    • Linting must pass
    • Build must succeed
    • Type checking must pass
  2. Code Review

    • At least one maintainer review
    • Address all feedback
    • Ensure code quality standards
  3. Final Testing

    • Manual testing by reviewer
    • Compatibility testing
    • Performance impact assessment

Issue Guidelines

Reporting Bugs

Use the bug report template:

Markdown
**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:

Markdown
**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

  • 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

.vscode/extensions.json
{
  "recommendations": [
    "bradlc.vscode-tailwindcss",
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "ms-vscode.vscode-typescript-next",
    "ms-playwright.playwright",
    "ms-vscode.vscode-json"
  ]
}

Environment Variables

Terminal
# 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:

  1. Create RFC (Request for Comments)

    • Document in docs/rfcs/
    • Explain problem and proposed solution
    • Get community feedback
  2. Discuss in Issues

    • Create GitHub issue for discussion
    • Tag relevant maintainers
    • Allow time for feedback
  3. 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:

  1. Check existing documentation
  2. Search GitHub issues
  3. Ask in GitHub Discussions
  4. Join Discord community
  5. 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 ! 🎉