There should be a version of --exact that doesn't apply to peerDependencies

[Dru89]

Expected Behavior

I should be able to update peerDependencies with version ranges, even if dependencies have exact versions. This would best support the "plugin" architecture that peerDependencies seems to mostly exist for.

Reading the documentation from npm:

Trying to install another plugin with a conflicting requirement will cause an error. For this reason, make sure your plugin requirement is as broad as possible, and not to lock it down to specific patch versions.

— https://docs.npmjs.com/files/package.json#peerdependencies

Current Behavior

Currently, version pinning is done with the --exact flag, and that extends to dependencies, peerDependencies, and devDependencies:

lerna/src/commands/PublishCommand.js

Lines 579 to 582 in da3e30f

	// update pkg dependencies
	this.updatePackageDepsObject(pkg, "dependencies", exact);
	this.updatePackageDepsObject(pkg, "devDependencies", exact);
	this.updatePackageDepsObject(pkg, "peerDependencies", exact);

Possible Solution

I think --exact should continue to do what it already does, so we don't have any breaking changes. But we could introduce flags like --[no-]exact-dependencies, --[no-]exact-peer-dependencies, and --[no-]exact-dev-dependencies to turn on/off specific dependencies sections.

Context

We use lerna to build a "framework" for applications, including a base package and a few plugins. This means that every application depends on a few plugins and then the base package. But with --exact, what will happen is that the peerDependencies for updated dependencies are kept in lock-step.

This seems to be against npm's recommendations for peerDependencies, and could put us in a position where two plugins can't be used at the same time, because of a strict peer dependency on the base package.

[evocateur]

In #1018 we've already agreed that lerna really shouldn't be touching peerDependencies at all, since changes to the peer range (especially the bottom end) are semver-major, and often very hard to automate safely. The linked issue gets a little in the weeds toward the end, but fundamentally we shouldn't be doing anything to peerDependencies right now (or "surprise" changes, as described in #955).

[Dru89]

Oh, cool. I'm okay closing this as a duplicate and just following #1018, then. Sorry, I tried to search for this but had a harder time finding it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lock]

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.