-
Notifications
You must be signed in to change notification settings - Fork 0
Contributing
- Branch off
develop(notmain). - Open a PR into
develop. GitGuardian security scanning runs automatically; theNode.js CIbuild check only runs on PRs targetingmain. - Once merged to
develop, open a second PR fromdevelopintomainto actually ship it (this repo's convention — every change lands onmainvia adevelop-sourced PR, never a direct feature-branch →mainPR). - Merging to
mainauto-deploys — see Deployment.
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.
npm run build # must be clean — no tsc errors
npm test # must be green — jest --passWithNoTestsThere's no npm run lint script yet despite .eslintrc.cjs existing — don't rely on it.
- Config:
jest.config.ts—ts-jestpreset, rootsrc/, 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.tsbase 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."
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.
- 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.