3.14.x: Prerelease publish failed to bump `version` in most `package.json` files.

This behavior is a scripted behavior which we’ve used for some time now, but seems to have broken with 3.14.1 (presumably 3.14.0 too, but we’d been using 3.13.4 before). Essentially, Lerna didn’t bump the versions for the packages it said it was going to bump, committed the one that it did update (the very first one), and then went on to try and publish — ultimately failing because it attempts to publish over the previously published version.

Expected Behavior

When running the following, I expect it to suggest bumping all the appropriate packages by a prerelease faction, prompt with proposed versions, and when confirmed, publish them to their appropriate prerelease versions (e.g. .alpha.n, in this case):

lerna publish --exact \
	--force-publish=apollo-server-core \
	--include-merged-tags \
	--preid alpha \
	--dist-tag next \
	prerelease 

As I expected, this yielded a prompt of suggested version bumps, as it typically does:

Changes:
 - apollo-datasource-rest: 0.4.0 => 0.4.1-alpha.0
 - apollo-engine-reporting: 1.2.0-alpha.3 => 1.2.0-alpha.4
 - apollo-server-azure-functions: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-cloud-functions: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-cloudflare: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-core: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-express: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-fastify: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-hapi: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-integration-testsuite: 2.6.0-alpha.3 => 2.6.0-alpha.4 (private)
 - apollo-server-koa: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-lambda: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-micro: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server-plugin-base: 0.5.0-alpha.3 => 0.5.0-alpha.4
 - apollo-server-testing: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - apollo-server: 2.6.0-alpha.3 => 2.6.0-alpha.4
 - graphql-extensions: 0.7.0-alpha.3 => 0.7.0-alpha.4

Two of these packages have relevancy to this bug, but I’ve included the full output for accuracy. Of note are:

apollo-datasource-rest: 0.4.0 => 0.4.1-alpha.0

and

apollo-server-fastify: 2.6.0-alpha.3 => 2.6.0-alpha.4

Those will be relevant in the next section.

Current Behavior

The above typically works, publishing the proposed packages accordingly (barring registry failures), but it appears that some characteristics that I believe are new to 3.14.x prevented it from updating all of the packages and it instead only committed (to Git) the package.json bump to the version property for the very first package (in this case, apollo-datasource-rest), and then proceeded to attempt to publish the other packages without bumping the version in their package.json’s, resulting in:

? Are you sure you want to publish these packages? Yes
lerna info execute Skipping GitHub releases
lerna info git Pushing tags...
lerna info publish Publishing packages to npm...
lerna info Verifying npm credentials
lerna http fetch GET 200 https://registry.npmjs.org/-/npm/v1/user 598ms
lerna http fetch GET 200 https://registry.npmjs.org/-/org/apollo-bot/package?format=cli 350ms
lerna http fetch PUT 403 https://registry.npmjs.org/apollo-server-fastify 569ms
lerna ERR! E403 You cannot publish over the previously published versions: 2.6.0-alpha.3

What’s happened here is that it’s tried publishing apollo-server-fastify@2.6.0-alpha.3 (.3), even though it said it was going to bump to and publish apollo-server-fastify@2.6.0-alpha.4 (.4).

Digging into the aftermath, I had the following commit on the tip of my branch (commit body expand-o’d in this <detail> for brevity):

The `Publish` commit

commit d25304e123f9176e1980e59e03ac57b03cf76f98
Author: Jesse Rosenberger <[e-mail]>
Date:   Thu May 23 19:30:10 2019 +0300

    Publish
    
     - apollo-datasource-rest@0.4.1-alpha.0
     - apollo-engine-reporting@1.2.0-alpha.4
     - apollo-server-azure-functions@2.6.0-alpha.4
     - apollo-server-cloud-functions@2.6.0-alpha.4
     - apollo-server-cloudflare@2.6.0-alpha.4
     - apollo-server-core@2.6.0-alpha.4
     - apollo-server-express@2.6.0-alpha.4
     - apollo-server-fastify@2.6.0-alpha.4
     - apollo-server-hapi@2.6.0-alpha.4
     - apollo-server-integration-testsuite@2.6.0-alpha.4
     - apollo-server-koa@2.6.0-alpha.4
     - apollo-server-lambda@2.6.0-alpha.4
     - apollo-server-micro@2.6.0-alpha.4
     - apollo-server-plugin-base@0.5.0-alpha.4
     - apollo-server-testing@2.6.0-alpha.4
     - apollo-server@2.6.0-alpha.4
     - graphql-extensions@0.7.0-alpha.4

diff --git a/packages/apollo-datasource-rest/package.json b/packages/apollo-datasource-rest/package.json
index 562d4c6b..6a7cfeb0 100644
--- a/packages/apollo-datasource-rest/package.json
+++ b/packages/apollo-datasource-rest/package.json
@@ -1,6 +1,6 @@
 {
   "name": "apollo-datasource-rest",
-  "version": "0.4.0",
+  "version": "0.4.1-alpha.0",
   "author": "[e-mail]",
   "license": "MIT",
   "repository": {

Most of the version bumps are missing here, and it would have been expected to bump the other packages it thought it wanted to bump as well.

It had, however, gone ahead and git tagged all the packages though (snipped some tags for brevity, again):

(HEAD -> release-2.6.0, tag: graphql-extensions@0.7.0-alpha.4, tag: apollo-server@2.6.0-alpha.4, ... tag: apollo-server-fastify@2.6.0-alpha.4, ...  tag: apollo-datasource-rest@0.4.1-alpha.0, origin/release-2.6.0)

And ultimately, it had published nothing. (I consider this a good thing, given its likely doomed fate!)

Steps to Reproduce (for bugs)

1. lerna publish --exact \
     --force-publish=apollo-server-core \
     --include-merged-tags \
    --preid alpha \
    --dist-tag next \
    prerelease 
   

lerna.json

{
  "packages": ["packages/*"],
  "version": "independent"
}

Context

I realize that undoing a failure here is difficult and there might be a better way to undo the failure, but in this case, I wasn’t sure as to the best approach. Typically, if it does the bumps and fails in an npm step, I’m still able to use from-git to use the committed details.

In this case, however, the commit was suggesting that a bunch of packages had been updated in its message but the versions were only bumped for one. I therefore deleted the new git tags both locally and on the remote server, my working tree to the previous (pre-Publish) commit via git reset --hard HEAD~ and tried the publish again.

Ultimately, I reverted to lerna@3.13.4, tried again, and had success.

Your Environment

Executable	Version
lerna --version	3.14.1
npm --version	6.9.0
node --version	10.15.1

OS	Version
NAME	VERSION
macOS Mojave	10.14.4

Happy to try and help however!

[nicolo-ribaudo]

Honestly, all the graph traversal stuff is extremely out of my wheelhouse. I’m very appreciative of the expert help here.

Don’t worry, I had to re-write the logic three times because initially I had no idea about what I was doing 😅 Fortunately things became clearer while I was working on it.

Our approaches are completely different: I think that with my approach lerna respects the topological order better, but @bweggersen is way simpler.

@bweggersen If you could give an opinion about my PR it would be really appreciated!

[nicolo-ribaudo]

I was going to write the same conclusion.

I’ll try to open a PR.

---

EDIT

The bug is deeper: after markAsDone is called, @babel/helper-replace-supers should become a leaf node.

---

EDIT 2

I believe that this is what is happening: (the arrow means “depends on”)

1. F is a leaf node: it is processed and removed
2. E has become a leaf node: it is processed and removed
3. There aren’t leaf nodes anymore (every node depends on something else), and there aren’t only cycles: lerna stops.

---

EDIT 3

I was wrong, the previous graph was correctly handled. The problem is when a cycle ha a parent from two different nodes:

It only executes B