Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
78 lines (52 loc) · 2.49 KB

CONTRIBUTING.md

File metadata and controls

78 lines (52 loc) · 2.49 KB

Contributing to Interactive Reversible Debugger

Thank you for helping improve this project. This document describes how we work and what we expect before a pull request is merged.

Getting started

  1. Fork the repository and clone your fork.

  2. Create a branch from main:

    git checkout -b your-feature-or-fix

  3. Install dependencies:

    npm ci

  4. Add a .env or .env.local from .env.example so the app and type-aware tooling can resolve import.meta.env at dev time. For tests only, the repo includes .env.test.

Before you open a pull request

Run the same checks as CI (see .github/workflows/ci.yml):

npm run lint
npm run typecheck
npm run test:run
npm run build

For build (and sometimes dev), set:

export VITE_SUPABASE_URL=https://test.supabase.co
export VITE_SUPABASE_ANON_KEY=test-key

On Windows (PowerShell):

$env:VITE_SUPABASE_URL="https://test.supabase.co"
$env:VITE_SUPABASE_ANON_KEY="test-key"
npm run build

Code style

  • TypeScript is strict; avoid any unless there is a strong reason and a narrow scope.
  • ESLint is the source of truth for lint rules; unused parameters should be prefixed with _ where applicable.
  • Match existing patterns in the file you edit (imports, naming, component structure).

Commits and pull requests

  • Write commit messages in the imperative mood (Add checkpoint scroll, not Added).
  • Keep PRs focused: one concern per PR when possible.
  • Describe what changed and why in the PR description.
  • Link related issues if any.

Tests

  • Prefer Vitest tests next to the code: *.test.ts under src/.
  • Add or update tests when you change behavior in pure functions (parsers, engines, helpers).
  • UI changes may use React Testing Library where it adds clear value; not every UI tweak requires a test.

Documentation

  • Update README.md or files under docs/ if you change setup, env vars, architecture, or Supabase expectations.

Security

  • Do not introduce eval, new Function, or dynamic execution of arbitrary user strings without an explicit, reviewed sandbox design.
  • Do not commit real Supabase service role keys or other secrets. The anon key is public by design in the client but still belongs in env files, not hardcoded.

Questions

Open an issue for design questions or larger proposals so maintainers can align before you invest in a big change.