Do not increment version if a devDep + peerDep?

[milesj]

Say we have packages foo, bar, and baz, with bar and baz having foo as a peer dependency. Both of these packages also have a dev dependency for foo so that npm/yarn install/symlink everything correctly.

Now, when foo is updated and I run lerna publish, it increments the foo dev dependency in bar and baz (even when they haven't been modified), which causes a patch version to be published for these 2 packages. These patch versions are completely unnecessary.

It would be nice to avoid this if possible, possibly through a CLI flag.

Expected Behavior

N/A, not sure it's scoped.

Current Behavior

It unnecessarily releases versions when devDeps are updated.

Possible Solution

Disable through a CLI flag? Don't increment devDep if also a peerDep?

Context

This is causing unnecessary patch releases for packages.

Your Environment

Executable	Version
lerna --version	3.10.7
npm --version	6.7.0
yarn --version	1.13.0
node --version	10.14.1

[evocateur]

Yeah, this seems fair. I think we've long yearned for some sort of distinction between dependencies and devDependencies when determining the transitive bumps...

[diegohaz]

Is this related to #1737?

[evocateur]

@diegohaz Yes, this is essentially what I was agreeing with you in that thread.

Potential pitfalls, off the top of my head:

1. When a peer's paired devDep is bumped a major version, that probably means the peer has been mutated, and we should allow the transitive bump. (which bump? ehhhh...)
2. Reading minds is hard, so it probably needs to be an explicit prompt/option.

[panayot-cankov]

Hello,

I have a similar issue on my end. I have a devDependency that generates some code and this code is reexported by several packages. I wish there was a mechanism to specify how the version change of one package affects the rest. E.g. somewhere in lerna confg to specify that MAJOR bump in foo would lead to MAJOR bump of baz.

Something like:

  "versionRelation": {
    "foo": {
      "baz": {
        "patch": "patch",
        "minor": "minor",
        "major": "major"
      }
    },
    "bar": {
      "baz": {
        "patch": "patch",
        "minor": "patch",
        "major": "patch"
      }
    }
  }

And that would basically mean that if lerna version figures out that "baz" was affected by "major" it should bump the version of "foo" with a "major". And if the version of "baz" was affected by a "major" change it would bump "bar" with just a "patch".

And there may be few semantic one-liner options like:

  "foo": {
    "baz": "reexport" // meaning that code from baz behaves as reexported by foo, and breaking changes in baz lead inevitably to breaking changes in foo, but that's by repo's design and is ok
    "bar": "none" // bar may be a dev dependency in foo but is merely a linter, so no matter what we do to bar, it won't affect the public api and overall behavior in foo
  }

[leonheess]

Is this dead?