lerna changed should ignore packages where the change should not result in a release.

It would be great if lerna change could analyse the changes coming in based not only on the files they affected, but also the type of change being introduced.

Expected Behavior

In a mono-repo using conventional commits, changes marked as chore, test, ci, docs, etc. should not result in a package affected being released.

This would be in line with the behaviour of the semantic-release module.

Current Behavior

The documentation states that lerna change supports ignoreChanges setting, but this doesn’t really help in this case. I would like the package to be released when the package.json change is marked as fix (say I updated a dep that had a security issue), but not when I’ve done a chore of tweaking an npm script.

Possible Solution

Look like collect-updates would have to be changed to recognise the commit messages that affected the files.

Steps to Reproduce (for bugs)

1. Create a mono-repo managed by lerna
2. Add dependabot service
3. See dependabot update your dev dependencies using an angular-style chore(packagename): ... comment
4. See lerna publish all the packages to npm even though they have only received chore updates to their devDependencies

lerna.json

{
  "lerna": "2.11.0",
  "loglevel": "info",
  "packages": [
    "documentation/*",
    "examples/*",
    "integration/*",
    "packages/*"
  ],
  "version": "2.0.8",
  "command": {
    "create": {
      "homepage": "https://serenity-js.org",
      "license": "Apache-2.0"
    },
    "version": {
      "allowBranch": "master",
      "conventionalCommits": true,
      "exact": true,
      "message": "chore(release): %s\n[ci skip]"
    },
    "publish": {
      "dist-tag": "latest"
    }
  },
  "ignoreChanges": [
    "**/documentation/**",
    "**/examples/**",
    "**/integration/**",
    "**/*.md",
    "**/spec/**"
  ],
}

Context

I’m trying to have lerna automatically version and publish the public packages at https://gihub.com/serenity-js/serenity-js without bumping the version numbers, polluting the changelog, and releasing the packages when it’s not necessary.

Your Environment

Please have a look at the repository at https://github.com/serenity-js/serenity-js

Executable	Version
lerna --version	3.20.2
npm --version	6.13.4
yarn --version	N/A
node --version	10.18.1

OS	Version
NAME	VERSION
Travis CI	travis-ci-sardonyx-xenial

[mohanraj-r]

On a related note want to bring up the discrepancy between lerna changed and lerna list.

While lerna list --since master e.g. is able to detect changes correctly and list packages accordingly, lerna changed neither supports the --since arg nor does the change detection correctly as lerna list. With lerna changed we get lerna info Assuming all packages changed. And lerna version seems to rely/model on lerna changed behavior rather than lerna list --since ... Is there a reason behind this? Could this be fixed e.g. to add --since behavior to lerna version similar to lerna list?

[jan-molak]

Thanks @joelmukuthu, I didn’t realise that this was the case. I simply assumed that respecting semantic release conventions would be a sensible thing for Lerna to do, hence this ticket.

I’m not entirely sure what @evocateur refers to in #1569 (comment) as “the fundamental contract of lerna”, so would love some more clarity on that.

I suppose another alternative would be to write some sort of a script, as per @hutson’s comment, that analysed the commits since the last release and invoked lerna publish only if they contained any patches/features/breaking changes, etc; or monkey-patch Lerna’s collect-updates.

Either approach smells of a hack, though, and I’d be much more keen for Lerna to enable some way for the user to configure the tool’s behaviour. I wouldn’t, of course, expect lerna to cater for every single possible use case, simply provide an extension point that would allow the user to inject whatever strategy/plugin is appropriate for their monorepo.

BTW: it looks like the upcoming 2.0 release of Yarn might provide an alternative solution to this problem - https://yarnpkg.com/features/release-workflow