Skip to content

Contributing

_david edited this page Aug 21, 2026 · 1 revision

Contributing

Workflow

  1. Branch off develop (not main).
  2. Open a PR into develop. GitGuardian security scanning runs automatically; the Node.js CI build check only runs on PRs targeting main.
  3. Once merged to develop, open a second PR from develop into main to actually ship it (this repo's convention — every change lands on main via a develop-sourced PR, never a direct feature-branch → main PR).
  4. Merging to main auto-deploys — see Deployment.

Branch naming

No strict convention, but most historical branches follow issue-<number>-<short-slug> when tied to a tracked issue, or <type>-<short-slug>-<date> (e.g. fix-idor-broken-access-control-2026-08-21) for undated/ad-hoc work.

Before opening a PR

npm run build   # must be clean — no tsc errors
npm test        # must be green — jest --passWithNoTests

There's no npm run lint script yet despite .eslintrc.cjs existing — don't rely on it.

Testing

  • Config: jest.config.tsts-jest preset, root src/, alias @/* → src/*.
  • Test files: src/__tests__/ and co-located *.test.ts.
  • Current coverage: auth (service + controller + refresh), middlewares (verifyToken, rateLimit, requestLogger), utils (bcrypt, valid), db connection.
  • Not covered: candidate profile, any of the 7 CV section controllers/services, candidate_me (public profile + PDF), services/index.ts base ops, querySafe, tokenBlacklist, i18n utils.

When intentionally changing response behavior (e.g. a message string, a default language, a function's parameter signature), update the corresponding test assertions in the same PR and say so explicitly in the PR description — don't let a broken assertion linger as "expected to fail."

Issue tracker

Bugs and feature proposals are tracked as GitHub Issues on this repo, using labels: bug, enhancement, security, refactor, testing, performance, devops, documentation. TODO.md at the repo root has a broader (though not always current) gap-analysis snapshot — cross-check it against actual code/issues before trusting it, since it isn't updated automatically as fixes land.

Commit / PR conventions

  • Conventional-ish prefixes: feat:, fix:, fix(security):, chore:, docs:, ci:, refactor:.
  • PR descriptions should include a Test plan checklist (build/test commands run, plus any manual/live verification performed) — this repo has a history of shipping bugs that only surfaced via live testing, not unit tests alone, so documenting what was actually exercised matters.

Clone this wiki locally