Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
55 lines (34 loc) · 3.84 KB

CONTRIBUTING.md

File metadata and controls

55 lines (34 loc) · 3.84 KB
Raw

Contributing to CommitLabs

First off, thank you for considering contributing to CommitLabs! It's people like you that make this tool great.

Before diving into the code, please read through our Developer Guide for comprehensive instructions on local setup, coding standards, and system architecture.

Branching

  1. Fork the repository and clone it locally.
  2. Ensure your fork is synced with the upstream master branch.
  3. Create a feature branch off of master using standard prefixes: feat/<description>, fix/<description>, docs/<description>, or test/<description>.

Editor Configuration

This repository ships an .editorconfig at the root to keep whitespace, charset, and line endings consistent across editors. Most editors support it natively or via a plugin. It enforces UTF-8, LF line endings, 2-space indentation, a final newline, and trailing-whitespace trimming (Markdown excepted, so hard line breaks are preserved). These rules are aligned with the ESLint config to avoid formatting-only diffs.

Toolchain

This project pins its toolchain so contributors and CI run a consistent environment:

  • Node.js: version 20 (see .nvmrc; run nvm use to switch). The engines field in package.json enforces >=20 <21.
  • Package manager: pnpm@9 (declared via packageManager and engines.pnpm).

engine-strict=true is set in .npmrc, so installs fail fast on an unsupported Node or pnpm version rather than producing subtle errors later.

Pull Request Flow

  1. Commit your changes logically and with clear, descriptive commit messages.
  2. Push your feature branch to your fork.
  3. Open a Pull Request (PR) against the master branch of the upstream repository.
  4. Provide a clear PR description explaining the context, what was changed, and how to verify it.
  5. Wait for a review from the maintainers and address any feedback promptly.

Test and Coverage Expectations

  • All new features and bug fixes must be accompanied by appropriate tests (Vitest).
  • We require a minimum of 95% test coverage on any new or changed logic.
  • Before opening your PR, run tests and check coverage locally using npm run test:coverage (or pnpm test:coverage).
  • The build, tests, and linters must pass in CI before the PR can be merged.

Frontend Performance Budgets

The production build is checked against gzip-compressed first-load JavaScript budgets for /, /create, and /dashboard. The baseline comes from the Next.js build output: 96.2 kB, 100 kB, and 99.8 kB, respectively. The exact byte baselines and limits (10% headroom) are recorded in performance-budgets.json; / has its own lower limit. The check also fails if the Freighter API implementation appears in the / first-load chunks.

After building, run npm run size; run npm run test:size to test the manifest parser and budget failure cases. To inspect bundle contents, run npm run analyze (which enables the analyzer only for that build).

Lighthouse CI checks /, /create, and /dashboard using three mobile runs and median assertions for performance, LCP, CLS, and TBT. Run it locally after building with npx lhci autorun. To intentionally update the budgets, rebuild and compare the route first-load values, confirm that Freighter remains out of / first-load JavaScript, then update the corresponding baseline and 10%-headroom maximum in performance-budgets.json in the same change.

96-Hour Timeframe Convention

To keep the momentum of the project moving, we enforce a 96-hour timeframe convention:

  • Once an issue is assigned to you, you are expected to submit a draft or open a PR within 96 hours.
  • If you receive feedback on your PR, please address it within 96 hours.
  • If there is no activity or communication within this window, the issue may be reassigned to another contributor.