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
- Contributing to Relizy
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)
bashnpm install -g pnpmGit installed and configured
Fork and Clone
Fork the repository on GitHub by clicking the "Fork" button
Clone your fork locally:
bashgit clone https://github.com/YOUR_USERNAME/relizy.git cd relizy
Install Dependencies
pnpm installThis will:
- Install all dependencies
- Set up Git hooks with Husky
- Prepare your development environment
Development Workflow
Build Commands
# Build the distribution (production build)
pnpm build
# Build in stub mode (faster, for development)
pnpm dev
# Type-check without emitting files
pnpm typecheckTesting Commands
# Run unit tests
pnpm test:unit
# Run tests in watch mode
pnpm test:unit:watch
# Run tests with coverage report
pnpm test:unit:coverageLinting Commands
# Run ESLint
pnpm lint
# Fix linting issues automatically
pnpm lint:fixTesting the CLI Locally
# Run the CLI during development
pnpm relizy <command> [options]
# or
pnpm rly <command> [options]Example:
pnpm relizy bump --dry-run
pnpm relizy release --helpProject Structure
Understanding the project structure will help you navigate the codebase:
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 filesKey Files to Know
src/cli.ts: CLI argument parsing and command routingsrc/core/version.ts: Core versioning logic (covered by tests)src/core/config.ts: Default configuration and config loadingsrc/types.ts: All TypeScript interfaces and typesvitest.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).
# Run all tests
pnpm test:unit
# Watch mode for TDD
pnpm test:unit:watch
# Generate coverage report
pnpm test:unit:coverageWriting Tests
When adding new functionality:
- Add tests in
/__tests__/directory - Follow the existing test patterns
- Ensure tests are deterministic and isolated
- Aim for meaningful coverage, not just high percentages
Example test:
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:
- Create a test monorepo structure
- Run the CLI with
--dry-runto preview changes - Test with different version modes and configurations
- Verify generated changelogs and version bumps
Code Style
TypeScript
- Use TypeScript for all new code
- Provide types for all exported functions and interfaces
- Avoid
anytype; useunknownor proper types - Prefer explicit return types for public APIs
ESLint
This project uses @maz-ui/eslint-config.
# Auto-fix linting issues
pnpm lint:fixKey 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:
- ESLint extension
- TypeScript + JavaScript
- Enable "Format on Save" with ESLint
Commit Guidelines
This project follows Conventional Commits:
Commit Format
<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
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 calculationsGit 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:
- Fix linting issues:
pnpm lint:fix - Fix type errors:
pnpm typecheck - Follow commit message format
Pull Request Process
Before Submitting
Update from upstream:
bashgit fetch upstream git rebase upstream/mainTest your changes:
bashpnpm typecheck pnpm lint pnpm test:unit pnpm buildUpdate 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
Push to your fork:
bashgit push origin your-branch-nameOpen a Pull Request on GitHub
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:
# Run tests with coverage locally
pnpm test:unit:coverage
# Open coverage report in browser
open coverage/index.htmlReview Process
- A maintainer will review your PR
- Address any requested changes
- Once approved, a maintainer will merge your PR
- Your contribution will be included in the next release! 🎉
Additional Resources
Documentation
- README.md - Project overview and usage
- Online Documentation - Full documentation site
Useful Links
- GitHub Repository
- Issues
- Changelogen - Underlying changelog tool
- Conventional Commits
Getting Help
- Questions? Open a question issue
- Found a bug? Report it
- Have an idea? Suggest a feature
Thank you for contributing to Relizy! Your efforts help make this project better for everyone. 🚀