Feature Request: Support for Non-Conventional Commits

[rabadin]

Problem statement

When integrating legacy codebases or older branches into projects using release-please, commits that don't follow the conventional commit format are silently ignored. This means:

• No version bumps occur despite code changes
• Legacy commits don't appear in changelogs
• Manual intervention is required to force releases
• Migration from non-conventional to conventional commits is difficult

This is particularly problematic when:

• Merging long-lived feature branches with pre-conventional commits
• Migrating legacy projects to release-please
• Working with teams transitioning to conventional commits
• Incorporating external contributions that don't follow conventions

Proposed Solution

PR: #2624

Add an optional configuration setting to add any number of mappings prefix -> conventional commit prefix that allows non-conventional commits or non-accounted for prefixes (like emojis) to be treated as a specified commit type.

Example Configuration

  {
    "extra-prefix-mapping": {
      "🐛": "fix",
      "change": "fix",
      "": "chore"
    }
  }

Behavior

When not configured (default): Current behavior.

When configured: new mappings prefix -> conventional commits prefix are taken into account.

[rabadin]

Hi Jeff (@chingor13). It looks like you've been randomly assigned to this issue that I've filed ;).

Would you mind having a look when you get a chance?

I understand this goes a bit against the philosophy of using conventional commits, but as I said in the issue, sometimes you must integrate legacy code. Some support for non-conventional commits (even if behind a setting) could therefore be helpful. It can also help teams transition gradually to conventional commits: they can start using release-please and then see the benefits—automatic determination of the next release and better changelog quality—that conventional commits provide.

I've created a draft PR for this: #2624

[Cussa]

I saw that there is this issue and PR, and I would like to add a "proposal": instead of simple considering a commit as a single type, we could have a map of the non convetional, with a default.

This would allow to support the #2385 automatically, as we could map the gitmoji to the types automatically.

[rabadin]

@Cussa Thanks for the suggestion! That's a generalization of what I had in mind. I like it: I've implemented it and updated the PR and the issue.

[rabadin]

@ferrarimarco / @chingor13 Hey guys... just following up on this issue in case it got lost. I’d appreciate any feedback when you have time.