Angular allow al types in changelog without needing a BREAKING CHANGE

[oalmeyda]

The ability to add other types of commits in release notes is necessary for non-user facing projects.

One possible way is to allow it via environment variables:

--- a/packages/conventional-changelog-angular/writer-opts.js
+++ b/packages/conventional-changelog-angular/writer-opts.js
@@ -33,6 +33,10 @@ function getWriterOpts () {
         discard = false
       })

+         if (process.env.DISCARD_OTHER_COMMIT_TYPES === 'FALSE') {
+           discard = false
+         }
+
       if (commit.type === 'feat') {
         commit.type = 'Features'
       } else if (commit.type === 'fix') {

[baby-gnu]

I personnaly switch from workaround angular to configured conventionalcommits with the following:

// …
const breakingKeywords = ["BREAKING CHANGE", "BREAKING-CHANGE", "BREAKING CHANGES", "BREAKING-CHANGES"];
const changelogFile = 'docs/CHANGELOG.md';

// https://github.com/conventional-changelog/conventional-changelog-config-spec/blob/master/versions/2.1.0/README.md
const commitTypes = [
  {type: "build",    section: "Build System",             hidden: false},
  {type: "chore",    section: "Maintenance",              hidden: true},
  {type: "ci",       section: "Continuous Integration",   hidden: false},
  {type: "docs",     section: "Documentation",            hidden: false},
  {type: "feat",     section: "Features",                 hidden: false},
  {type: "fix",      section: "Bug Fixes",                hidden: false},
  {type: "perf",     section: "Performance Improvements", hidden: false},
  {type: "refactor", section: "Code Refactoring",         hidden: false},
  {type: "revert",   section: "Reverts",                  hidden: false},
  {type: "style",    section: "Styles",                   hidden: false},
  {type: "test",     section: "Tests",                    hidden: false},
];
// …
  plugins: [
    [
      '@semantic-release/commit-analyzer',
      {
        preset: 'conventionalcommits',
        parserOpts:
        {
          noteKeywords: breakingKeywords,
        },
        releaseRules: './release-rules.js',
        presetConfig:
        {
          types: commitTypes,
        },
      },
    ],
    [
      '@semantic-release/release-notes-generator',
      {
        preset: 'conventionalcommits',
        parserOpts:
        {
          noteKeywords: breakingKeywords,
        },
        presetConfig:
        {
          types: commitTypes,
        },
      },
    ],
  ],
};

// …

See also #421.

[ipleten]

I personnaly switch from workaround angular to configured conventionalcommits with the following:

// …
const breakingKeywords = ["BREAKING CHANGE", "BREAKING-CHANGE", "BREAKING CHANGES", "BREAKING-CHANGES"];
const changelogFile = 'docs/CHANGELOG.md';

// https://github.com/conventional-changelog/conventional-changelog-config-spec/blob/master/versions/2.1.0/README.md
const commitTypes = [
  {type: "build",    section: "Build System",             hidden: false},
  {type: "chore",    section: "Maintenance",              hidden: true},
  {type: "ci",       section: "Continuous Integration",   hidden: false},
  {type: "docs",     section: "Documentation",            hidden: false},
  {type: "feat",     section: "Features",                 hidden: false},
  {type: "fix",      section: "Bug Fixes",                hidden: false},
  {type: "perf",     section: "Performance Improvements", hidden: false},
  {type: "refactor", section: "Code Refactoring",         hidden: false},
  {type: "revert",   section: "Reverts",                  hidden: false},
  {type: "style",    section: "Styles",                   hidden: false},
  {type: "test",     section: "Tests",                    hidden: false},
];
// …
  plugins: [
    [
      '@semantic-release/commit-analyzer',
      {
        preset: 'conventionalcommits',
        parserOpts:
        {
          noteKeywords: breakingKeywords,
        },
        releaseRules: './release-rules.js',
        presetConfig:
        {
          types: commitTypes,
        },
      },
    ],
    [
      '@semantic-release/release-notes-generator',
      {
        preset: 'conventionalcommits',
        parserOpts:
        {
          noteKeywords: breakingKeywords,
        },
        presetConfig:
        {
          types: commitTypes,
        },
      },
    ],
  ],
};

// …

See also #421.

Can you please elaborate a bit how to use this?
I'm trying to add conventional commits with additional types to lerna and can't find any documentation.

[baby-gnu]

Can you please elaborate a bit how to use this? I'm trying to add conventional commits with additional types to lerna and can't find any documentation.

Hello.

You can find a complete example of configuration in my ci-tools .releaserc.js config file.

With the following diff, you could add a foo keyword to generate a Foo section section which trigger a patch level version bump:

commit 2728e059c8e5b82b2e86a0b2e6d2e2924780116e
Author: Daniel Dehennin <daniel.dehennin@ac-dijon.fr>
Date:   Wed Mar 29 08:40:12 2023 +0200

    foo(semantic-release): try the foo section

diff --git a/.releaserc.js b/.releaserc.js
index a4cff44..5b18882 100644
--- a/.releaserc.js
+++ b/.releaserc.js
@@ -45,6 +45,7 @@ const commitTypes = [
   { type: "revert",   section: "Reverts",                  hidden: false},
   { type: "style",    section: "Styles",                   hidden: false},
   { type: "test",     section: "Tests",                    hidden: false},
+  { type: "foo",      section: "Foo section",              hidden: false},
 ];
 
 const releaseRules = [
@@ -60,6 +61,7 @@ const releaseRules = [
   { type: 'revert',     release: 'patch' },
   { type: 'style',      release: 'patch' },
   { type: 'test',       release: 'patch' },
+  { type: 'foo',        release: 'patch' },
 ];
 
 const semanticBranches = [stableBranch];

When running semantic-release, I got:

semantic-release --dry-run --branches $(git symbolic-ref --short HEAD)

[6:52:13 AM] [semantic-release] › ℹ  Running semantic-release version 19.0.3
[…]
[6:52:21 AM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[6:52:21 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: foo(semantic-release): try the foo section
[6:52:21 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[…]
[6:52:21 AM] [semantic-release] › ℹ  Release note for version 1.0.0:
## 1.0.0 (2023-03-29)

### Features

[…]

### Foo section

    * semantic-release: try the foo section (2728e05 (https://gitlab.com/baby-gnu/ci-tools/commit/2728e059c8e5b82b2e86a0b2e6d2e2924780116e))

Note that I did not yet look for the way to change the sorting order.

Regards.

[baby-gnu]

Note that I did not yet look for the way to change the sorting order.

Found it 😉

[baby-gnu]

Note that I did not yet look for the way to change the sorting order.

Found it wink

The sorting order can be done quite simply on the ordering of the commitTypes array:

diff --git a/.releaserc.js b/.releaserc.js
index 5b18882..86eb6e2 100644
--- a/.releaserc.js
+++ b/.releaserc.js
@@ -47,6 +47,11 @@ const commitTypes = [
   { type: "test",     section: "Tests",                    hidden: false},
   { type: "foo",      section: "Foo section",              hidden: false},
 ];
+// Group commit by type and sort the sections according to `commitTypes` sorting
+const commitGroups = commitTypes.map((e) => { return e.section; });
+function commitGroupsSortFn(a, b) {
+  return commitGroups.indexOf(a.title) - commitGroups.indexOf(b.title);
+};
 
 const releaseRules = [
   { breaking: true,     release: 'major' },
@@ -115,6 +120,10 @@ const config = {
         {
           noteKeywords: breakingKeywords,
         },
+        writerOpts:
+        {
+          commitGroupsSort: commitGroupsSortFn,
+        },
         presetConfig:
         {
           types: commitTypes,

Changing the order of commitTypes elements will modify the changelog sections ordering automatically.

Thanks for your question, it gave me the opportunity to look for the solution 👍