Scoped Refactor Commit

The refactor Type with Scope

A refactor commit restructures existing code without changing its external behavior. When combined with a scope, it clearly communicates which module or area of the codebase was refactored.

Example

refactor(database): replace raw SQL queries with query builder

Migrate all repository methods from string-concatenated SQL
to the Knex query builder. This improves type safety,
prevents SQL injection, and makes queries database-agnostic.

When to Use refactor

Use refactor when you:

• Restructure code without changing behavior
• Extract functions, classes, or modules
• Rename variables, functions, or files
• Simplify complex logic
• Apply design patterns

Do not use refactor when:

• Fixing a bug (use fix)
• Adding new functionality (use feat)
• Improving performance (use perf)
• Changing formatting only (use style)

Scope Guidelines for Refactoring

Since refactoring often touches multiple files, choose the scope that represents the primary area of change:

refactor(auth): extract token validation middleware
refactor(models): normalize database entity relationships
refactor(utils): split string helpers into separate modules
refactor(tests): convert callback-based tests to async/await

Version Impact

Refactoring commits typically do not trigger a version bump in semantic-release configurations. They are internal changes that should not affect consumers. However, they appear in changelogs under a "Refactoring" or "Code Changes" section, which is useful for contributors.

Common Pitfalls

• Mixing refactoring with features: If you refactor code and add a feature in the same commit, use feat. The feature is the more significant change.
• Overly broad scopes: refactor(app): restructure everything is too vague. Break it into smaller, focused commits.