feat: add new bump option "prefix"

[moroine]

Use Case:

Let's say we have:

• 2 packages with the following dependency chain a --> b (a is a deps of b & c)

Here are the package.json definition of a & b in the repository (we use 0.0.0 to force using local versions):

{
  "name": "a",
  "version": "0.0.0",
}

{
  "name": "b",
  "version": "0.0.0",
  "peerDependencies": {
     "a": "^0.0.0"
   }
}

When publishing the new version 1.0.1 the published package.json will be:

{
  "name": "b",
  "version": "1.0.1",
  "peerDependencies": {
     "a": "^1.0.1"
   }
}

[antongolub]

@moroine,

Could plz clarify why --deps.bump='inherit' does not produce the same effect?

[moroine]

Because looks like deps.bump will just check if current version satisfy requirement. Hence it will check if 1.0.1 satisfy^0.0.0. But because it doesn't satisfy, it will bump the version package to 1.0.1 without keeping the ^.

I've added a test to be able to compare differences with inherit strategy. I was originally thinking of using inherit but this would be a breaking change

[moroine]

@antongolub what do you think about this?

[antongolub]

Perhaps, we have an inaccuracy in describing of 'bump.inherit' behavior. Let's look on the test instead:

describe("resolveNextVersion()", () => {
	// prettier-ignore
	const cases = [
		["1.0.0", "1.0.1", undefined, "1.0.1"],
		["1.0.0", "1.0.1", "override", "1.0.1"],

		["*", "1.3.0", "satisfy", "*"],
		["^1.0.0", "1.0.1", "satisfy", "^1.0.0"],
		["^1.2.0", "1.3.0", "satisfy", "^1.2.0"],
		["1.2.x", "1.2.2", "satisfy", "1.2.x"],

		["~1.0.0", "1.1.0", "inherit", "~1.1.0"],
		["1.2.x", "1.2.1", "inherit", "1.2.x"],
		["1.2.x", "1.3.0", "inherit", "1.3.x"],
		["^1.0.0", "2.0.0", "inherit", "^2.0.0"],
		["*", "2.0.0", "inherit", "*"],
		["~1.0", "2.0.0", "inherit", "~2.0"],
		["~2.0", "2.1.0", "inherit", "~2.1"],
	]

If ["~1.0", "2.0.0", "inherit", "~2.0"] works why ["^0.0.0", "1.0.0", "inherit", "^1.0.0"] does not — that's what i'm trying to figure out.

[moroine]

@antongolub did you got time to have a look at it?

[dbouwman]

@antongolub we are also running into a similar issue where the ^ is being removed.

I my test project, I ran changes that should have hit this test case (in dependencies and peerDependencies)

["^1.0.0", "2.0.0", "inherit", "^2.0.0"],

except that it actually inserted "2.0.0" when running in a real release.

[antongolub]

@moroine, @dbouwman,

Maybe it's better to introduce override-prefix? So we could also pass ~.

[moroine]

@antongolub this is very problematic. Do you prefer to add this PR or still want to find out if this is a bug.

About override-prefix I think that's a good idea, but what would be the value of deps.bump ?

[antongolub]

@moroine, there's no bug as I can see now. And your feature is not covered by satisfy strtegy, I was wrong. So I suggest tweaking a bit your PR:

1. Introduce --deps.prefix = '' | '^' | '~' that will be attached to the next v if --deps.bump === 'override'.
2. Refactor resolveReleaseType, updateManifestDeps

I've landed your proposal on our experimental fork: https://github.com/qiwi/multi-semantic-release/pull/70/files

[moroine]

@antongolub your changes are excellent, I've also used your descriptions 😄

What are the differences with qiwi/multi-semantic-release? Does it respect the dependencies order, but maximize parallelization?

[antongolub]

The main diff: @qiwi fork replaces concurrent event-driven flow with toposort-based queues. It's definitely slower, but it's easier to debug our proprietary plugins.

[antongolub]

hmm... npm v7+ works with monorepos as well

[moroine]

Yeah, but the repository is using yarn.lock and npm will ignore yarn.lock and create package-lock.json; hence this will remove the advantage of having lock file

[antongolub]

The idea is clear, but I've never seen this kind of restriction anywhere else) Maybe it would be enough just to add package-lock.json to gitignore instead?

[moroine]

@antongolub I revert this change

[antongolub]

@moroine, LGTM, I'm ready to merge. But could you check what happens if:

if (scope[dependency.name]) {
	scope[dependency.name] = resolveNextVersion(dependency._lastRelease?.version || '0.0.0', dependency._nextRelease?.version, bumpStrategy, prefix);
} 

I think it would be better if only resolveNextVersion implted prefix handling logic.

[antongolub]

@moroine, this works:

const { isObject, isEqual, transform, get } = require("lodash");
//...
if (scope[dependency.name]) {
    scope[dependency.name] = resolveNextVersion(
	get(dependency, "_lastRelease.version", "0.0.0"),
	release.version,
	bumpStrategy,
	prefix
    );
}

[antongolub]

@moroine, finally merged.

Thanks a lot for your improvements and for your patience! The new feature will be available in v2.13.0.

[antongolub]

🎉 This PR is included in version 2.13.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀