Skip to content

Contributing to Relizy

Thank you for considering contributing to Relizy! We appreciate your interest in improving this project. This guide will help you get started with contributing.

Table of Contents

Code of Conduct

This project adheres to the Contributor Covenant Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to me@loicmazuel.com.

How Can I Contribute?

Reporting Bugs

If you find a bug, please open an issue using the bug report template. Include:

  • A clear, descriptive title
  • Steps to reproduce the issue
  • Expected vs actual behavior
  • Your environment (OS, Node version, package manager)
  • Relevant logs or error messages
  • Minimal reproduction (if possible)

Suggesting Features

Have an idea for a new feature? Open a feature request with:

  • A clear description of the feature
  • The problem it solves
  • Use cases and examples
  • Alternative solutions you've considered

Asking Questions

If you have questions about using Relizy, please open a question issue. We're here to help!

Contributing Code

We welcome code contributions! Here's how to get started:

Development Setup

Prerequisites

Before you begin, ensure you have:

  • Node.js >= 20.0.0

  • pnpm (this project uses pnpm exclusively)

    bash
    npm install -g pnpm
  • Git installed and configured

Fork and Clone

  1. Fork the repository on GitHub by clicking the "Fork" button

  2. Clone your fork locally:

    bash
    git clone https://github.com/YOUR_USERNAME/relizy.git
    cd relizy

Install Dependencies

bash
pnpm install

This will:

  • Install all dependencies
  • Set up Git hooks with Husky
  • Prepare your development environment

Development Workflow

Build Commands

bash
# Build the distribution (production build)
pnpm build

# Build in stub mode (faster, for development)
pnpm dev

# Type-check without emitting files
pnpm typecheck

Testing Commands

bash
# Run unit tests
pnpm test:unit

# Run tests in watch mode
pnpm test:unit:watch

# Run tests with coverage report
pnpm test:unit:coverage

Linting Commands

bash
# Run ESLint
pnpm lint

# Fix linting issues automatically
pnpm lint:fix

Testing the CLI Locally

bash
# Run the CLI during development
pnpm relizy <command> [options]
# or
pnpm rly <command> [options]

Example:

bash
pnpm relizy bump --dry-run
pnpm relizy release --help

Project Structure

Understanding the project structure will help you navigate the codebase:

text
relizy/
├── src/
│   ├── cli.ts                  # CLI entry point with Commander.js
│   ├── types.ts                # TypeScript type definitions
│   ├── commands/               # CLI command implementations
│   │   ├── bump.ts             # Version bumping logic
│   │   ├── changelog.ts        # Changelog generation
│   │   ├── provider-release.ts # GitHub/GitLab release creation
│   │   ├── publish.ts          # NPM publishing
│   │   ├── release.ts          # Complete release workflow
│   │   └── social.ts           # Social media posting
│   └── core/                   # Core business logic
├── bin/
│   └── relizy.mjs              # CLI executable entry point
├── .github/                    # GitHub templates and workflows
├── docs/                       # VitePress documentation
└── tests/                      # Test files

Key Files to Know

  • src/cli.ts: CLI argument parsing and command routing
  • src/core/version.ts: Core versioning logic (covered by tests)
  • src/core/config.ts: Default configuration and config loading
  • src/types.ts: All TypeScript interfaces and types
  • vitest.config.ts: Test configuration

Testing

Unit Tests

Tests are written using Vitest.

Currently, unit tests focus on src/core/version.ts (see vitest.config.ts).

bash
# Run all tests
pnpm test:unit

# Watch mode for TDD
pnpm test:unit:watch

# Generate coverage report
pnpm test:unit:coverage

Writing Tests

When adding new functionality:

  1. Add tests in /__tests__/ directory
  2. Follow the existing test patterns
  3. Ensure tests are deterministic and isolated
  4. Aim for meaningful coverage, not just high percentages

Example test:

typescript
import { describe, expect, it } from 'vitest'
import { someFunction } from '../version'

describe('someFunction', () => {
  it('should handle basic case', () => {
    expect(someFunction('1.0.0')).toBe('1.0.1')
  })
})

Manual Testing

For end-to-end testing:

  1. Create a test monorepo structure
  2. Run the CLI with --dry-run to preview changes
  3. Test with different version modes and configurations
  4. Verify generated changelogs and version bumps

Code Style

TypeScript

  • Use TypeScript for all new code
  • Provide types for all exported functions and interfaces
  • Avoid any type; use unknown or proper types
  • Prefer explicit return types for public APIs

ESLint

This project uses @maz-ui/eslint-config.

bash
# Auto-fix linting issues
pnpm lint:fix

Key rules:

  • No unused variables
  • Consistent quote style (single quotes)
  • Trailing commas where valid
  • No console statements (use proper logging)

Editor Setup

For the best development experience, use Visual Studio Code with:

Commit Guidelines

This project follows Conventional Commits:

Commit Format

text
<type>(<scope>): <subject>

[optional body]

[optional footer]

Types

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • chore: Maintenance tasks
  • refactor: Code refactoring
  • test: Adding or updating tests
  • perf: Performance improvements
  • ci: CI/CD changes
  • build: Build system changes

Examples

bash
feat(bump): add support for custom suffix in prerelease versions
fix(publish): handle 2FA OTP prompt correctly
docs(readme): update installation instructions
refactor(git): extract tag resolution logic
test(version): add tests for semver calculations

Git Hooks

Pre-commit hooks are set up with Husky and lint-staged:

  • Lints staged files before commit
  • Runs type-checking
  • Validates commit message format

If your commit is rejected:

  1. Fix linting issues: pnpm lint:fix
  2. Fix type errors: pnpm typecheck
  3. Follow commit message format

Pull Request Process

Before Submitting

  1. Update from upstream:

    bash
    git fetch upstream
    git rebase upstream/main
  2. Test your changes:

    bash
    pnpm typecheck
    pnpm lint
    pnpm test:unit
    pnpm build
  3. Update documentation if needed:

    • Update README.md for user-facing changes
    • Add/update examples if introducing new features
    • Update docs/src/ if needed

Submitting the PR

  1. Push to your fork:

    bash
    git push origin your-branch-name
  2. Open a Pull Request on GitHub

  3. Fill out the PR template with:

    • Description of changes
    • Type of change (feature, bug fix, etc.)
    • Related issues
    • Testing performed

PR Guidelines

  • Keep PRs focused on a single concern
  • Write clear PR titles following conventional commits format
  • Reference related issues (e.g., "Closes #123")
  • Respond to review feedback promptly
  • Ensure CI checks pass
  • Maintain code coverage: Codecov will comment on your PR

Code Coverage Requirements

This project uses Codecov to track code coverage. When you submit a PR, Codecov will automatically:

  • 📊 Comment with coverage diff
  • 📁 Show coverage for each modified file
  • ✅ Run status checks

Coverage Requirements:

  • Overall project: Coverage must not decrease by more than 0.5%
  • New code (patch): Must have at least 80% coverage

If Codecov checks fail, add more tests to cover your code:

bash
# Run tests with coverage locally
pnpm test:unit:coverage

# Open coverage report in browser
open coverage/index.html

Review Process

  1. A maintainer will review your PR
  2. Address any requested changes
  3. Once approved, a maintainer will merge your PR
  4. Your contribution will be included in the next release! 🎉

Additional Resources

Documentation

Getting Help


Thank you for contributing to Relizy! Your efforts help make this project better for everyone. 🚀

Released under the MIT License.