commit type

refactor commit template

A commit that restructures existing code without changing its observable behaviour — no new features and no bug fixes.

refactor(scope): short imperative description of the restructuring - what was restructured or extracted (bullet 1) - what was renamed or moved (bullet 2) - what was simplified or removed (bullet 3) Why the refactor improves the codebase: maintainability, testability, performance model, or alignment with current patterns. Max 72 chars/line.
refactor(auth): extract token validation into standalone TokenValidator - move verifyToken logic from AuthMiddleware into TokenValidator class - inject TokenValidator through constructor for testability - delete duplicate token parsing in AdminMiddleware that duplicated auth logic AuthMiddleware had grown to 400 lines; the extraction makes token logic independently testable and removes a duplication that had already drifted out of sync with the main path.
refactor(db): replace raw SQL strings with query builder throughout - migrate 14 hand-crafted SELECT strings to knex query builder calls - remove sql-template-strings dependency no longer needed after migration - add ESLint rule to disallow new string-concatenated queries Raw SQL strings were not type-checked and had caused two injection-adjacent bugs in code review; the query builder provides structural guarantees and consistent parameterisation.
refactor(api): flatten nested error-handling callbacks with async/await - convert 6 handler functions from callback pyramid to async/await - remove custom asyncWrap helper now that all handlers are native async - standardise error propagation via next(err) in catch blocks Callback nesting made control flow hard to follow during code review; async/await reduces cognitive overhead and makes the error path linear.
refactor(config): consolidate environment variable reading to single module - create src/config/index.ts that reads and validates all env vars at startup - replace 23 scattered process.env accesses with imports from config module - add Zod schema validation with descriptive error messages on missing vars Scattered env reads made it impossible to see the full config surface in one place; centralising them also moves validation to startup rather than request time.

Use refactor when the external behaviour stays the same but the internal code structure, organisation, naming, or readability improves. If any observable output changes, it is a feat or fix, not a refactor.

git-agent automatically analyzes your changes and infers the correct commit type.

brew install gitagenthq/tap/git-agent
Does refactor trigger a version bump?
No. refactor commits do not trigger version bumps in standard semantic-release configuration because they represent no change in observable behaviour for users or consumers.
Should I test that behaviour is preserved after a refactor?
Yes. The definition of a refactor is unchanged observable behaviour. If you don't have tests covering the refactored code, write them before refactoring. This is the essence of test-driven refactoring.
What is the difference between refactor and style commits?
style covers purely cosmetic changes that do not affect logic: whitespace, formatting, missing semicolons. refactor involves meaningful structural changes to how code is organised, named, or how concerns are separated.