Two branches both bumped a package to 1.42.0, git merged them without a conflict, and one release never shipped

the registry's 1.42.0 does NOT contain any of the changes below

Every gate was green, and the package was wrong anyway. That's the whole story, really, but how it actually happens is worth walking through, because I'd bet your pipeline has the same hole in it.

Symptom

The registry said the right thing. npm view returned 1.42.0, the CI publish guard had reported success, and nothing in the pipeline was red. Absolutely nothing.

But the build sitting in the registry was not the build we'd meant to ship. We installed the published package, asserted what was actually inside it, and got this: the registry's 1.42.0 does NOT contain any of the changes below. None of them. Not a partial set, not an old snapshot of them, just the other branch's work wearing our version number.

The repository was 3d-kit-design, and the date was 2026-09-10. That same day we noticed, which is only because we went looking inside the tarball instead of trusting the version string. Anyway, hold that thought, because it's the lesson.

What we thought it was

My first guess was a publish failure. You know the usual suspects: a flaky registry, a stale cache, an upload that half-completed and left a partial artefact behind. All of those are real things that happen, and all of them would produce a package that looks right in metadata and wrong in content.

It was believable because the symptom matched. A version that exists but contains the wrong files is exactly what a botched upload looks like. So I went and checked the publish logs, expecting an error I'd missed.

There wasn't one. The publish step had, in a sense, done its job perfectly. That was the unsettling bit. A failed upload leaves a trace, and this had left none, because nothing had failed.

Root cause

Here's what actually happened, and it's almost boring once you see it.

One branch published a new street assembly as 3d-kit 1.42.0 and merged to main. A second release branch had been cut earlier, from the same parent, and it also bumped package.json from 1.41.0 to 1.42.0. Two branches, two independent edits, and the edit was the same on both sides: line 3 of package.json, the version field, changed from one string to another.

If you look at package.json:3@4c59257 you're looking at the version line as one side left it. package.json:3@720e5bb is the other side's version of that line, and package.json:3@2dde125 is where the two met on main. Same string in all of them where it counted.

And git merges identical edits cleanly. I mean, of course it does. If both sides changed a line to the same value, there is no conflict to report, so git reported none. No marker, no prompt, no human ever asked to look at line 3.

So the second branch arrived on main carrying a version that was already taken. Then CI ran the publish guard, and the guard did the correct thing. It checked the registry, saw that 1.42.0 was already published, and skipped the release. Correct behaviour, genuinely, since republishing a version is something you must never do.

Put those two correct behaviours together and you get a silent failure. The merge was right. The guard was right. The release that contained the second branch's changes simply never happened, and everything downstream still reported 1.42.0 as present, because it was. It just wasn't ours.

The fix

The immediate repair was a re-cut. The second branch's changes went out as 1.43.0, on the same day we detected the problem, 2026-09-10. A package with the right content under a fresh version number, verified the same way we'd found the fault: install it, assert what's inside.

The durable repair came later. On 2026-09-12 (commit 9fa3c13) versions moved to being allocated on main by CI from changeset files. Branches no longer carry a version at all.

Think about what that removes. The failing condition needed two branches to each claim a version number independently, and a number a branch never writes is a number it can't collide on. Instead of each branch guessing the next free value, one place hands them out in order, after merge, when the real sequence is known.

Why it happened

The systemic cause is that the version was a piece of shared mutable state that every release branch edited by hand. Two people can't both be right about what comes next when neither can see the other's work, and cutting a branch earlier from a common parent guarantees exactly that blindness.

Review didn't catch it because there was nothing to review. A diff showing line 3 going from 1.41.0 to 1.42.0 looks routine, and on the merged result it looked like one change instead of two colliding ones. The identical strings are what hid it. A conflict would have been loud; agreement was silent.

And the gates all measured the wrong thing. They checked that a version existed, not that the version contained what we'd intended. Existence is cheap to verify and easy to confuse with correctness.

How to avoid it

First, stop letting branches choose version numbers. Allocate them in one place, after merge, from something declarative like changeset files. If a human or a branch writes the number, you've rebuilt the race.

Second, treat "already published, skipping" as a warning, not a success. A guard that skips a release should say loudly that content may not have shipped, because from the pipeline's point of view a skipped release and a completed one can both end green.

Third, and this is the one I'd keep if I could only keep one: verify the artefact, not the metadata. Install what's in the registry and assert its contents against what you meant to publish. That's the only check that would have failed here, and it's the only reason we found this at all.

Version strings tell you a name was claimed. They tell you nothing about what's inside, which is, anyway, the thing you actually shipped.