Contributing Guide

How to contribute to DevDaily, including PR process and coding standards

Welcome Contributors!

Thank you for your interest in contributing to DevDaily! This guide will help you submit high-quality contributions.

New to open source? Check out First Timers Only for guidance.

Getting Started

Fork and Clone

1. Fork the repository

   Visit github.com/hempun10/devdaily and click Fork

2. Clone your fork

   git clone https://github.com/<your-username>/devdaily.git
   cd devdaily
   
3. Install dependencies

   npm install
   
4. Verify setup

   npm run typecheck
   npm run lint
   npm test
   npm run build
   

If all commands complete successfully, you’re ready to contribute!

Development Workflow

1. Create a Branch

Create a feature branch from main:

git checkout -b feat/your-feature-name

Use descriptive branch names that indicate the type of change:

• feat/add-notion-integration
• fix/clipboard-copy-error
• docs/update-installation-guide

2. Make Your Changes

Write Code

Implement your feature or fix

Add Tests

Write tests for new functionality

Update Docs

Document user-facing changes

Follow Standards

Adhere to coding standards

3. Run Quality Checks

Before committing, ensure all checks pass:

npm run typecheck   # TypeScript compilation
npm run lint        # ESLint
npm run format      # Prettier formatting
npm test            # Vitest test suite
npm run build       # Production build

Pull requests with failing checks will not be merged.

4. Commit Your Changes

Follow the commit convention:

git add .
git commit -m "feat: add JSON output format for standup command"

5. Push and Create PR

git push origin feat/your-feature-name

Then open a pull request on GitHub against the main branch.

Coding Standards

TypeScript Style

Use strict mode

Strict mode is enabled - no any types unless absolutely necessary.

// Good ✓
function processData(data: unknown): string {
  if (typeof data === 'string') {
    return data;
  }
  throw new Error('Invalid data');
}

// Bad ✗
function processData(data: any): string {
  return data;
}

Add JSDoc comments

All public functions should have JSDoc comments.

/**
 * Generates a standup summary from git commits
 * @param days - Number of days to look back
 * @returns Formatted standup text
 */
export async function generateStandup(days: number): Promise<string> {
  // Implementation
}

Prefer async/await

Use async/await over raw promises for better readability.

// Good ✓
async function fetchData() {
  const response = await fetch(url);
  const data = await response.json();
  return data;
}

// Avoid ✗
function fetchData() {
  return fetch(url)
    .then(response => response.json())
    .then(data => data);
}

Use readonly when appropriate

Mark properties that shouldn’t be mutated as readonly.

interface Config {
  readonly apiKey: string;
  readonly endpoint: string;
}

Code Formatting

Formatting is enforced by ESLint and Prettier:

Rule	Value
Indentation	2 spaces
Quotes	Single quotes
Semicolons	Required
Trailing commas	ES5 style
Line width	100 characters
Line endings	LF (Unix)

Run npm run lint:fix and npm run format to auto-fix formatting issues.

File Organization

1. One export per file (when possible)

   Makes imports clear and code easier to navigate

2. Co-locate tests in tests/ directory

   Match source file names: src/core/notifications.ts → tests/notifications.test.ts

3. Keep commands thin

   Commands should orchestrate, not contain business logic. Put logic in src/core/

Commit Convention

DevDaily uses Conventional Commits, enforced by commitlint.

Format

<type>(<optional scope>): <description>

[optional body]

[optional footer(s)]

Commit Types

Type	Description	Example
feat	New feature	feat: add JSON output format
fix	Bug fix	fix(pr): handle repos with no default branch
docs	Documentation only	docs: update installation instructions
style	Formatting (no logic change)	style: fix indentation
refactor	Code change (no fix or feature)	refactor(journal): extract serialization logic
perf	Performance improvement	perf: optimize git log parsing
test	Adding or updating tests	test: add webhook integration tests
build	Build system or dependencies	build: upgrade to typescript 5.7
ci	CI configuration	ci: add Node.js 22 to test matrix
chore	Other changes	chore: update .gitignore
revert	Revert previous commit	revert: revert feat: add JSON output

Examples

Feature

feat: add Slack thread support for notifications

Commit Rules

• Use lowercase for the description
• Don’t end with a period
• Use imperative mood (“add feature” not “added feature”)
• Keep the first line under 72 characters

Pull Request Process

PR Title Format

Use the same conventional commit format:

feat: add Slack thread support for notifications
fix: clipboard copy failing on plain format

PR Checklist

1. Fill out the PR template

   Describe what changed and why

2. Keep PRs focused

   One feature or fix per PR - smaller PRs are easier to review

3. Add tests

   New features and bug fixes must include tests

4. Update documentation

   If your change affects user-facing behavior, update README or help text

5. Ensure CI passes

   All checks must pass: typecheck, lint, format, tests, and build

6. Respond to feedback

   Address review comments promptly

We aim to review PRs within a few days. Feel free to ping if you haven’t heard back.

Testing Requirements

Writing Tests

Every new feature or bug fix should include tests:

Unit Tests

// tests/new-feature.test.ts
import { describe, it, expect } from 'vitest';
import { newFeature } from '../src/core/new-feature.js';

describe('newFeature', () => {
  it('returns expected output for valid input', () => {
    const result = newFeature('test');
    expect(result).toBe('expected');
  });

  it('throws error for invalid input', () => {
    expect(() => newFeature('')).toThrow('Invalid input');
  });
});

Integration Tests

// tests/workflow.test.ts
import { describe, it, expect, vi } from 'vitest';

describe('standup workflow', () => {
  it('generates standup from commits', async () => {
    // Mock git operations
    // Test full workflow
  });
});

Running Tests

npm test                                    # All tests
npx vitest run tests/new-feature.test.ts   # Specific file
npm run test:watch                          # Watch mode
npm run test:coverage                       # With coverage

Tests must not require network access, git repositories, or API keys. Use mocks for external dependencies.

Code of Conduct

This project follows the Contributor Covenant Code of Conduct. Key points:

Be Respectful

Treat everyone with respect and kindness

Be Inclusive

Welcome diverse perspectives and experiences

Be Professional

Focus on constructive feedback and collaboration

Report Issues

Report unacceptable behavior by opening an issue

Reporting Issues

Bug Reports

When filing a bug report, include:

1. Version information

   devdaily --version
   node --version
   
2. Operating system

   e.g., macOS 14.0, Ubuntu 22.04, Windows 11

3. Steps to reproduce

   What commands you ran and what happened

4. Expected vs actual behavior

   What you expected to see vs what actually happened

5. Debug output

   Run the failing command with --debug and include the output

Feature Requests

For feature requests:

1. Check existing issues to avoid duplicates
2. Describe the problem your feature would solve
3. Suggest a possible approach if you have one
4. Label with enhancement

Need Help?

Issues

Browse existing issues

README

Read the documentation

Doctor

Run devdaily doctor for diagnostics

Recognition

All contributors are recognized in the project:

• Contributors listed in GitHub contributors page
• Significant contributions mentioned in release notes
• First-time contributors welcomed in PR comments

Thank you for contributing to DevDaily! Your contributions help make developer workflows better for everyone.

Next Steps

Setup Guide

Set up your development environment

Architecture

Understand the project structure

Testing

Learn about testing approach