Using Custom Commit Types

Extending the Standard Types

While the Conventional Commits specification only requires feat and fix, most projects adopt the Angular convention with 11 standard types. Some teams go further and add custom types to fit their specific workflow.

Common Custom Types

Custom Type	Purpose	When to Use
wip	Work in progress	Feature branches; squash before merge
hotfix	Emergency production fix	Urgent patches deployed outside normal release
release	Release preparation	Version bumps, changelog updates
deps	Dependency updates	Alternative to chore(deps)
security	Security patches	CVE fixes, vulnerability remediation
i18n	Internationalization	Translation files, locale support
a11y	Accessibility	ARIA labels, keyboard navigation, contrast
ux	User experience	UI/UX improvements that aren't features

Adding Custom Types in the Linter

In the Options panel, enter comma-separated custom types:

wip, hotfix, release, deps, security

These are appended to the default list. The linter will accept commits using any of the standard or custom types.

Team Guidelines

When adding custom types, document them in your project's CONTRIBUTING.md or commit convention guide:

## Commit Types

Standard types: feat, fix, docs, style, refactor, perf,
test, build, ci, chore, revert

Custom types:
- `wip`: Work in progress (squash before merging)
- `hotfix`: Emergency production fix
- `deps`: Dependency update

Tooling Configuration

If you use commitlint, configure custom types in commitlint.config.js:

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', [
      'feat', 'fix', 'docs', 'style', 'refactor',
      'perf', 'test', 'build', 'ci', 'chore', 'revert',
      'wip', 'hotfix', 'deps'
    ]]
  }
};

When to Avoid Custom Types

• If the change fits a standard type, use the standard type.
• Avoid types that are too specific: button-style-fix is better as fix(ui).
• Avoid types that overlap with standard ones: bugfix duplicates fix.