@exadev/semantic-release-workspace 3.0.2 → 3.0.3

package/dist/cli.js

@@ -14,7 +14,7 @@ import { generateNotes } from "@semantic-release/release-notes-generator";
 import semanticRelease from "semantic-release";
 import { pathToFileURL } from "node:url";
 //#region package.json
-var version = "3.0.2";
+var version = "3.0.3";
 //#endregion
 //#region src/errors.ts
 /**
@@ -910,6 +910,26 @@ function parsePublishPluginSpec(spec) {
 	const [name, config] = spec;
 	return [name, config ?? {}];
 }
+/**
+* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
+*
+* This exists because semantic-release cannot tell the orchestrator apart the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
+*
+* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
+*
+* A package whose answer is never established fails the run. Returning "nothing to release" for it would be a guess, and the guess that loses is exactly the silent partial release this loop exists to stop.
+*/
+async function releasePackageAcrossBranchMoves(name, branch, attempt, log) {
+	for (let moves = 1;; moves += 1) {
+		const tipBefore = await branch.integrate();
+		const outcome = await attempt();
+		if (outcome.released) return outcome;
+		const tipAfter = await branch.tip();
+		if (tipAfter === tipBefore) return outcome;
+		if (moves >= 3) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
+		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
+	}
+}
 //#endregion
 //#region src/pnpm.ts
 /**
@@ -1341,7 +1361,7 @@ async function runReleaseLoop(graph, order, workspace, dryRun, log, releaseOne)
 		const pkg = mustGet(graph.packages, name, "package");
 		const bumpsForThisPackage = pendingBumps.get(name) ?? [];
 		log(`Releasing ${name} from ${pkg.relativeDirectory}${bumpsForThisPackage.length > 0 ? ` (dependency ranges already bumped: ${bumpsForThisPackage.map((bump) => bump.dependency).join(", ")})` : ""}`);
-		const { released, version, result } = await releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne);
+		const { released, version, result } = dryRun ? await releaseOne(pkg, bumpsForThisPackage) : await releasePackageAcrossBranchMoves(name, branchTracker(workspace, log), async () => await releaseOne(pkg, bumpsForThisPackage), log);
 		entries.push({
 			name,
 			directory: pkg.directory,
@@ -1439,12 +1459,6 @@ async function bumpDependents(released, version, graph, options) {
 	return applied;
 }
 /**
-* How many times one package may be re-released after the branch moved underneath its own attempt, before the run gives up loudly.
-*
-* There is no option for this and no derivation from a measured rate, unlike `pushAttempts`, because the shape of the problem is different. Integration happens at most once per package boundary, so the loop is already bounded by the size of the workspace; this only bounds the pathological case where the branch moves during the same package's own attempt over and over. Each round costs one package's analysis, and a branch would have to move during three consecutive attempts at the same package to exhaust it, at which point the run is being starved rather than raced and saying so is more useful than trying again.
-*/
-const MAX_BRANCH_MOVES_PER_PACKAGE = 3;
-/**
 * Brings the checkout up to the release branch's current tip, and reports where that tip is.
 *
 * At a package boundary every commit this run has made is already on the remote (each release commit by `@semantic-release/git`'s own prepare push, each tag by semantic-release's own, each dependency bump by `pushHead`), so advancing onto a moved branch is a fast-forward and loses nothing. `fastForwardTo` refuses anything else rather than discarding local work, which would mean the assumption above had broken.
@@ -1459,24 +1473,12 @@ async function integrateBranchTip(workspace, log) {
 	log(`${packageName}: ${branch} advanced to ${tip} during this run; integrated it before continuing.`);
 	return tip;
 }
-/**
-* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
-*
-* This exists because semantic-release cannot tell the orchestrator the difference between the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
-*
-* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
-*/
-async function releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne) {
-	if (dryRun) return await releaseOne(pkg, bumpsForThisPackage);
-	for (let moves = 0;; moves += 1) {
-		const tipBefore = await integrateBranchTip(workspace, log);
-		const outcome = await releaseOne(pkg, bumpsForThisPackage);
-		if (outcome.released) return outcome;
-		const tipAfter = await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root });
-		if (tipAfter === tipBefore) return outcome;
-		if (moves + 1 >= MAX_BRANCH_MOVES_PER_PACKAGE) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves + 1)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
-		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
-	}
+/** The release branch as `releasePackageAcrossBranchMoves` needs to see it, backed by the real repository. */
+function branchTracker(workspace, log) {
+	return {
+		integrate: async () => await integrateBranchTip(workspace, log),
+		tip: async () => await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root })
+	};
 }
 //#endregion
 //#region src/gate-publish.ts

package/dist/index.cjs

@@ -908,6 +908,26 @@ function parsePublishPluginSpec(spec) {
 	const [name, config] = spec;
 	return [name, config ?? {}];
 }
+/**
+* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
+*
+* This exists because semantic-release cannot tell the orchestrator apart the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
+*
+* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
+*
+* A package whose answer is never established fails the run. Returning "nothing to release" for it would be a guess, and the guess that loses is exactly the silent partial release this loop exists to stop.
+*/
+async function releasePackageAcrossBranchMoves(name, branch, attempt, log) {
+	for (let moves = 1;; moves += 1) {
+		const tipBefore = await branch.integrate();
+		const outcome = await attempt();
+		if (outcome.released) return outcome;
+		const tipAfter = await branch.tip();
+		if (tipAfter === tipBefore) return outcome;
+		if (moves >= 3) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
+		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
+	}
+}
 //#endregion
 //#region src/pnpm.ts
 /**
@@ -1489,7 +1509,7 @@ async function runReleaseLoop(graph, order, workspace, dryRun, log, releaseOne)
 		const pkg = mustGet(graph.packages, name, "package");
 		const bumpsForThisPackage = pendingBumps.get(name) ?? [];
 		log(`Releasing ${name} from ${pkg.relativeDirectory}${bumpsForThisPackage.length > 0 ? ` (dependency ranges already bumped: ${bumpsForThisPackage.map((bump) => bump.dependency).join(", ")})` : ""}`);
-		const { released, version, result } = await releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne);
+		const { released, version, result } = dryRun ? await releaseOne(pkg, bumpsForThisPackage) : await releasePackageAcrossBranchMoves(name, branchTracker(workspace, log), async () => await releaseOne(pkg, bumpsForThisPackage), log);
 		entries.push({
 			name,
 			directory: pkg.directory,
@@ -1587,12 +1607,6 @@ async function bumpDependents(released, version, graph, options) {
 	return applied;
 }
 /**
-* How many times one package may be re-released after the branch moved underneath its own attempt, before the run gives up loudly.
-*
-* There is no option for this and no derivation from a measured rate, unlike `pushAttempts`, because the shape of the problem is different. Integration happens at most once per package boundary, so the loop is already bounded by the size of the workspace; this only bounds the pathological case where the branch moves during the same package's own attempt over and over. Each round costs one package's analysis, and a branch would have to move during three consecutive attempts at the same package to exhaust it, at which point the run is being starved rather than raced and saying so is more useful than trying again.
-*/
-const MAX_BRANCH_MOVES_PER_PACKAGE = 3;
-/**
 * Brings the checkout up to the release branch's current tip, and reports where that tip is.
 *
 * At a package boundary every commit this run has made is already on the remote (each release commit by `@semantic-release/git`'s own prepare push, each tag by semantic-release's own, each dependency bump by `pushHead`), so advancing onto a moved branch is a fast-forward and loses nothing. `fastForwardTo` refuses anything else rather than discarding local work, which would mean the assumption above had broken.
@@ -1607,24 +1621,12 @@ async function integrateBranchTip(workspace, log) {
 	log(`${packageName}: ${branch} advanced to ${tip} during this run; integrated it before continuing.`);
 	return tip;
 }
-/**
-* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
-*
-* This exists because semantic-release cannot tell the orchestrator the difference between the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
-*
-* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
-*/
-async function releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne) {
-	if (dryRun) return await releaseOne(pkg, bumpsForThisPackage);
-	for (let moves = 0;; moves += 1) {
-		const tipBefore = await integrateBranchTip(workspace, log);
-		const outcome = await releaseOne(pkg, bumpsForThisPackage);
-		if (outcome.released) return outcome;
-		const tipAfter = await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root });
-		if (tipAfter === tipBefore) return outcome;
-		if (moves + 1 >= MAX_BRANCH_MOVES_PER_PACKAGE) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves + 1)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
-		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
-	}
+/** The release branch as `releasePackageAcrossBranchMoves` needs to see it, backed by the real repository. */
+function branchTracker(workspace, log) {
+	return {
+		integrate: async () => await integrateBranchTip(workspace, log),
+		tip: async () => await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root })
+	};
 }
 //#endregion
 exports.DEFAULT_PUBLISH_PLUGINS = DEFAULT_PUBLISH_PLUGINS;

package/dist/index.js

@@ -883,6 +883,26 @@ function parsePublishPluginSpec(spec) {
 	const [name, config] = spec;
 	return [name, config ?? {}];
 }
+/**
+* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
+*
+* This exists because semantic-release cannot tell the orchestrator apart the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
+*
+* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
+*
+* A package whose answer is never established fails the run. Returning "nothing to release" for it would be a guess, and the guess that loses is exactly the silent partial release this loop exists to stop.
+*/
+async function releasePackageAcrossBranchMoves(name, branch, attempt, log) {
+	for (let moves = 1;; moves += 1) {
+		const tipBefore = await branch.integrate();
+		const outcome = await attempt();
+		if (outcome.released) return outcome;
+		const tipAfter = await branch.tip();
+		if (tipAfter === tipBefore) return outcome;
+		if (moves >= 3) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
+		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
+	}
+}
 //#endregion
 //#region src/pnpm.ts
 /**
@@ -1464,7 +1484,7 @@ async function runReleaseLoop(graph, order, workspace, dryRun, log, releaseOne)
 		const pkg = mustGet(graph.packages, name, "package");
 		const bumpsForThisPackage = pendingBumps.get(name) ?? [];
 		log(`Releasing ${name} from ${pkg.relativeDirectory}${bumpsForThisPackage.length > 0 ? ` (dependency ranges already bumped: ${bumpsForThisPackage.map((bump) => bump.dependency).join(", ")})` : ""}`);
-		const { released, version, result } = await releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne);
+		const { released, version, result } = dryRun ? await releaseOne(pkg, bumpsForThisPackage) : await releasePackageAcrossBranchMoves(name, branchTracker(workspace, log), async () => await releaseOne(pkg, bumpsForThisPackage), log);
 		entries.push({
 			name,
 			directory: pkg.directory,
@@ -1562,12 +1582,6 @@ async function bumpDependents(released, version, graph, options) {
 	return applied;
 }
 /**
-* How many times one package may be re-released after the branch moved underneath its own attempt, before the run gives up loudly.
-*
-* There is no option for this and no derivation from a measured rate, unlike `pushAttempts`, because the shape of the problem is different. Integration happens at most once per package boundary, so the loop is already bounded by the size of the workspace; this only bounds the pathological case where the branch moves during the same package's own attempt over and over. Each round costs one package's analysis, and a branch would have to move during three consecutive attempts at the same package to exhaust it, at which point the run is being starved rather than raced and saying so is more useful than trying again.
-*/
-const MAX_BRANCH_MOVES_PER_PACKAGE = 3;
-/**
 * Brings the checkout up to the release branch's current tip, and reports where that tip is.
 *
 * At a package boundary every commit this run has made is already on the remote (each release commit by `@semantic-release/git`'s own prepare push, each tag by semantic-release's own, each dependency bump by `pushHead`), so advancing onto a moved branch is a fast-forward and loses nothing. `fastForwardTo` refuses anything else rather than discarding local work, which would mean the assumption above had broken.
@@ -1582,24 +1596,12 @@ async function integrateBranchTip(workspace, log) {
 	log(`${packageName}: ${branch} advanced to ${tip} during this run; integrated it before continuing.`);
 	return tip;
 }
-/**
-* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
-*
-* This exists because semantic-release cannot tell the orchestrator the difference between the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
-*
-* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
-*/
-async function releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne) {
-	if (dryRun) return await releaseOne(pkg, bumpsForThisPackage);
-	for (let moves = 0;; moves += 1) {
-		const tipBefore = await integrateBranchTip(workspace, log);
-		const outcome = await releaseOne(pkg, bumpsForThisPackage);
-		if (outcome.released) return outcome;
-		const tipAfter = await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root });
-		if (tipAfter === tipBefore) return outcome;
-		if (moves + 1 >= MAX_BRANCH_MOVES_PER_PACKAGE) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves + 1)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
-		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
-	}
+/** The release branch as `releasePackageAcrossBranchMoves` needs to see it, backed by the real repository. */
+function branchTracker(workspace, log) {
+	return {
+		integrate: async () => await integrateBranchTip(workspace, log),
+		tip: async () => await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root })
+	};
 }
 //#endregion
 export { DEFAULT_PUBLISH_PLUGINS, DependencyCycleError, GitCommandError, ReleaseConfigurationError, SINGLE_COMMIT_DEFAULT_PUBLISH_PLUGINS, UnsupportedDependencyRangeError, WorkspaceDiscoveryError, WorkspaceReleaseError, WorkspaceStateError, buildDependencyGraph, classifyDependencyRange, createScopedPlugins, discoverWorkspace, filterCommitsToDirectory, orderedPackages, packageName, readManifest, releaseWorkspace, resolvePublishPlugins, resolveWorkspacePublishPlugins, resumeWorkspaceRelease, topologicalOrder, updateDependencyRange, writeDependencyRange };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@exadev/semantic-release-workspace",
-  "version": "3.0.2",
+  "version": "3.0.3",
   "description": "Independent per-package semantic-release orchestration for pnpm workspaces, without lockstep versioning.",
   "type": "module",
   "repository": {