question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

With conventional commits, patch version is unexpectedly always increased

See original GitHub issue

#1547 speaks more of this, but is closed.

Expected Behavior

  • Have any package at version 1.0.0
  • Make a change to this package and commit with chore: fix typo in readme
  • Run lerna publish --yes as part of your CI
  • Nothing is published, as a chore does not warrant a release

Current Behavior

  • Have any package at version 1.0.0
  • Make a change to this package and commit with chore: fix typo in readme
  • Run lerna publish --yes as part of your CI
  • Version 1.0.1 of package is published

Possible Solution

The version command should take an array of commit types to either whitelist of blacklist from affecting the bumping of a version.

Whitelist: only commits with these types can trigger a bump in version, other commits are completely ignored.

{
  "command": {
    "version": {
      "conventionalCommits": true,
      "conventionalWhitelist": [
        "feat",
        "fix"
      ],
      "message": "chore: release --skip-ci"
    }
  }
}

Blacklist: Commits with these types are completely ignored and cannot trigger a bump in version.

{
  "command": {
    "version": {
      "conventionalCommits": true,
      "conventionalBlacklist": [
        "chore"
      ],
      "message": "chore: release --skip-ci"
    }
  }
}

Steps to Reproduce (for bugs)

See expected and current behaviour section.

lerna.json

{
  "version": "independent",
  "npmClient": "yarn",
  "useWorkspaces": true,
  "packages": [
    "packages/*"
  ],
  "publishConfig": {
    "access": "restricted"
  },
  "command": {
    "version": {
      "allowBranch": "master",
      "conventionalCommits": true,
      "changelogPreset": "angular",
      "createRelease": "github",
      "commitHooks": "false",
      "message": "chore: release --skip-ci"
    }
  }
}

Context

We have a monorepo using Lerna to release and link a bunch of packages, but we also have Dependabot creating pull requests for dependency updates on a daily basis.

We like to stay up to date with our dependencies, as that is significantly easier than updating a dependency you haven’t updated in a year. But now every time we update aws-sdk (for example, a very active package), Lerna publishes a new patch version of all our packages using aws-sdk.

Now that’s annoying, but what happens next is that Dependabot creates pull requests for other repositories (both ours and for people all over the internet) with this amazing new release where the aws-sdk dependency has been updated.

This is creating a lot of noise for us, and likely for the users of our packages too.

Next to that, if I fix a typing error in a README, I really don’t see any reason to release a new version of the package for that. It’s completely useless.

Your Environment

Executable Version
lerna --version 3.19.0
npm --version 6.12.1 (not used)
yarn --version 1.21.1
node --version 12.13.1
OS Version
macOS Catalina 10.15.1
Ubuntu 18.04

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:6
  • Comments:7

github_iconTop GitHub Comments

2reactions
cmurczek-itcommented, Nov 2, 2020

As far as I can tell, it’s Lerna taking an opinionated (and IMHO very questionable) decision right here: https://github.com/lerna/lerna/blob/master/core/conventional-commits/lib/recommend-version.js#L54

Can anybody from the team share some insights or reasoning on why Lerna feels the need to override the versioning recommendation given by the configured preset?

1reaction
SleepWalkercommented, Mar 18, 2021

Looks like this behavior of meaningless releases will stay with lerna, because it’s not a bug but a feature 😅 . See #1569

Read more comments on GitHub >

github_iconTop Results From Across the Web

Semantic Versioning(SemVer) with Conventional Commits
Changing version numbers should always have an incremental form. ... More details about SemVer rules could be found in Semantic Versioning Specification.
Read more >
Generating changelog automatically with Standard Version
If our new release increases just the patch version number means ... To do that, we need to follow a Conventional Commits specification....
Read more >
conventional commit messaging - Conventional Commits
Anyone who has upgraded to a new patch version of a dependency, only to watch their application start throwing a steady stream of...
Read more >
Bump - Commitizen
The version is bumped automatically based on the commits. The commits should follow the rules of the committer to be parsed correctly.
Read more >
Conventional Commits vs. Release-It and Chatting About the ...
[09:12] - A mild smackdown on conventional commits versus release-it. [15:23] - Why Chuck and Robbie prefer the changelog.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found