publish-npm.yml cannot succeed on first tag push (aborts on adk version collision), and the obvious fix would ship a 75-line sdk@3.0.0 over the real 2.0.14

[yakimoto]

publish-npm.yml is the right design — OIDC trusted publishing, provenance, an environment gate, per-package preview/latest tagging. It is also, as written, unable to succeed on its first real tag push, and if that first failure is fixed the obvious way it ships a 75-line shell over a real package.

Both come from the same three lines:

set -euo pipefail
for dir in packages/*/; do
  ...
  ( cd "$dir" && pnpm publish --access public --provenance --no-git-checks --tag "$tag" )
done

Bug 1 — the loop aborts on the first package, every time

The glob expands alphabetically, so packages/adk/ is always first. adk is at 1.0.14 locally and 1.0.14 on npm (published from elsewhere — see #42). npm rejects a republish of an existing version, pnpm publish exits non-zero, and under set -e a failing subshell in command position kills the whole job.

Three of the four packages that exist on npm are exact version collisions:

Package	local	npm	on pnpm publish
adk	1.0.14	1.0.14	collision → job dies here
mcp-server	0.1.8	0.1.8	collision
workflow-sdk	1.0.6	1.0.6	collision
sdk	3.0.0	2.0.14	no collision

So git tag sdks-v… && git push --tags publishes nothing and reports failure — including the 45 packages that have never been published and genuinely should be.

I have not been able to run this: Actions is billing-locked org-wide (wave-rig#174), so the reasoning above is from the source and the registry, not from a run. The version numbers and the glob order are measured; the set -e abort is read from the script.

Bug 2 — the fix that suggests itself is worse than the bug

The natural repair is "skip a version that already exists." Do only that, and sdk becomes the first package to get through — and sdk here is 2 files, 75 lines, versioned 3.0.0, against a real @wave-av/sdk@2.0.14 with 16 versions behind it.

case "$ver" in 0.0.*) tag=preview sends only 0.0.x to preview. 3.0.0 is not 0.0.x, so it goes to latest. Every consumer of @wave-av/sdk would resolve to the shell on their next install, and semver would present it as the newest stable release.

This is the same failure wave-av/adk#64 was opened to prevent, in a second location and with a wider blast radius — adk#64 guards a fork nobody depends on; this guards the package with the most published history in the scope.

Suggested fix — skip collisions, but refuse regressions

Two independent conditions, because they fail differently. Skipping an already-published version is routine; publishing behind the registry is never intended and should stop the job.

set -euo pipefail
for dir in packages/*/; do
  name=$(node -p "require('./${dir}package.json').name" 2>/dev/null) || continue
  case "$name" in @wave-av/*) ;; *) continue ;; esac
  ver=$(node -p "require('./${dir}package.json').version")
  published=$(npm view "$name" version 2>/dev/null || echo "0.0.0")

  # Already on the registry at this exact version: nothing to do. Not an error —
  # a monorepo-wide tag will always include packages that did not change.
  if [ "$ver" = "$published" ]; then
    echo "skip $name@$ver — already published"
    continue
  fi

  # Behind the registry: the local copy is not the source of truth for this package.
  # Never let semver present it as newer. Hard fail — this needs a human.
  newest=$(printf '%s\n%s\n' "$ver" "$published" | sort -V | tail -1)
  if [ "$newest" != "$ver" ]; then
    echo "::error::$name is $ver locally but npm serves $published — refusing to publish backwards (see #42)"
    exit 1
  fi

  tag=latest; case "$ver" in 0.0.*) tag=preview ;; esac
  echo "publishing $name@$ver --tag $tag"
  ( cd "$dir" && pnpm publish --access public --provenance --no-git-checks --tag "$tag" )
done

Note this deliberately still fails on sdk, because sdk@3.0.0 being a 75-line shell is a real problem that a workflow should not paper over. The guard turns a silent bad release into a loud stop.

One thing I got wrong in #42

I recommended "fix the repository fields first." For this repo that is already done — all 49 packages point at wave-av/sdks, which is exactly what provenance requires, and the workflow's (satisfied) comment is accurate. The wrong repository metadata is in the published artifacts, because they were built from a different source copy. Nothing to fix here.

Also worth confirming before arming this

The header says the workflow is inert until a Trusted Publisher is registered on npmjs.com for this repo + this workflow + the npm-publish environment. Worth confirming that is still unregistered — if it were registered, a tag push would already be live, and Bug 1 is the only thing that has been preventing a bad release.

Related: #42 (which repo publishes what), wave-av/adk#64 (same guard, adk fork).

[coderabbitai]

🔗 Related PRs

#9 - fix(publish): available registry names (rust→wave-sdk, pypi→wave-av-sdk) [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[yakimoto]

Fix opened as #45 — both bugs, plus a two-pass structure so a single bad package cannot strand the ones that sort after it.

Correcting one thing I wrote above: I said the version guard "deliberately still fails on sdk." It does not. sort -V puts 3.0.0 ahead of 2.0.14, so a version-only guard waves it straight through to latest. I only caught that by running the loop with the publish stubbed rather than reasoning about it.

What actually catches it is comparing tarball size against the published release — 4,749 bytes vs 994,775. That check is in #45.

[yakimoto]

Correction: packages/sdk is the meta-package. It was never a shell.

I've described sdk-typescript/packages/sdk repeatedly as "2 files, 75 lines, a shell, a leftover name pointing at nothing," and built an argument on top of that. It's wrong, and it's the most consequential thing I've gotten wrong in this audit.

src/index.ts re-exports all 44 product namespaces:

export * from "@wave-av/core";
export * as clips from "@wave-av/clips";
export * as voice from "@wave-av/voice";
...44 total

and package.json declares every one of them as a workspace:* dependency. That is a meta-package — the exact thing I proposed building as "option (a)" for this package's future. It already exists.

A re-export barrel is supposed to be short. I used line count as a proxy for completeness, and for a barrel that proxy is inverted: 75 lines is what correct looks like. Same mistake I made on mcp-server (read the version, not the tree), one layer up — this time I read the file size, not the file.

The 3.0.0 major is also defensible on that reading, not suspicious: 2.0.14 was one monolithic 994KB aggregate; 3.0.0 is a thin barrel over 44 separately-installable packages. That's a real breaking change, deliberately made.

The actual hazard is worse than the one I described

Every one of those 44 dependencies is checked against the public registry:

meta-package dependencies: 44
published on npm:          0
NOT published:             44

core clips voice captions chapters editor phone collab podcast studio-ai transcribe sentiment search studio fleet mesh edge scene pipeline cloud-switcher creator audience marketplace distribution connect slides desktop signage qr usb camera-control prompter replay pulse prism zoom vault drm billing notifications ghost autopilot console discovery

So publishing @wave-av/sdk@3.0.0 today doesn't ship an empty package — it ships one whose every dependency is unresolvable. npm install @wave-av/sdk would fail outright for every consumer, replacing a 2.0.14 that installs and works. A shell at least installs. This bricks the install.

What this means for #45

#45's tarball-size guard does block this release — 4,749B against a published 994,775B — but for the wrong reason, and that matters:

• It reports "package is less than half the size of the one it replaces," which mis-diagnoses a correctly-small barrel as a truncated package.
• It would keep blocking the meta-package after the 44 are published and the release becomes correct. The guard would have to be disabled at exactly the moment it's supposed to be trusted, which is how guards get routed around.

The right check for this class is dependency resolvability: refuse to publish if any dependency won't resolve on the registry at the version being published. That catches this precisely, stays silent once the 44 are shipped, and generalizes to every package in the workspace rather than special-casing one.

I'll add that to #45. The size guard still earns its place for the genuinely-truncated case, but it should not be the thing standing between us and a correct release.

The ordering constraint this exposes

The umbrella cannot publish before its contents. The 44 product packages must reach npm first, then @wave-av/sdk. That's a hard sequencing requirement for the release plan, and it wasn't in my earlier recommendation because I thought the umbrella was empty rather than waiting.

On the reliability of this audit

That's four corrections now: mcp-server's tool count, the sdk@3.0.0 risk direction, the wave-av/sdk repo's role, and this. The measured tables — file counts, LOC, gitHead containment, registry state — have held up every time. What has repeatedly failed is my characterization of what a thing is for, inferred from a cheap signal (a version number, a line count) instead of reading it. Weight the numbers here; treat any sentence of mine describing intent as provisional until you've read the file.

[yakimoto]

Correcting my own correction: I overstated the meta-package hazard

Earlier today I wrote that publishing @wave-av/sdk@3.0.0 "ships one whose every dependency is unresolvable — npm install @wave-av/sdk would fail outright for every consumer." I built that on the measurement that 0 of its 44 dependencies are on npm.

The measurement is right. The conclusion doesn't follow. This workflow publishes the whole workspace in one run, and all 44 dependencies are in that workspace. In a normal coordinated release they publish alongside the umbrella, pnpm rewrites workspace:* to the real versions, and the result installs correctly. I checked the count and never checked whether it mattered.

I found this while writing the guard the claim implied. Building it forced me to test it against the actual workspace, and it would have rejected 45 of 49 packages — because nearly all of them depend on @wave-av/core, which is equally unpublished. A guard derived from a true fact and a false inference, and the fact that it fired on almost everything is what exposed the inference.

What is actually wrong — narrower, and real

The publish loop iterates packages/*/ — alphabetical order, not dependency order — and runs under set -euo pipefail. So a failure partway through leaves everything before it already published.

sdk sorts before eleven of its own dependencies:

… scene, sdk, search, sentiment, signage, slides, studio-ai, studio,
  transcribe, usb, vault, voice, zoom

If the run dies anywhere after sdk and before zoom, @wave-av/sdk@3.0.0 is live on npm with up to eleven dependencies that were never published — and npm does not validate dependency existence at publish time, so nothing stops it. That leaves a broken package as latest, permanently, because npm versions can't be replaced.

This is not specific to sdk; it's any package that sorts before something it depends on. @wave-av/adk depends on @wave-av/kernel, and adk sorts first.

Filed separately as #46. The fix is to publish in topological order rather than alphabetical — pnpm -r already topo-sorts for build and pack, so the ordering is available; the publish loop just doesn't use it.

What shipped to #45

The dependency check, rewritten to the rule that survives testing: reject a dependency that exists neither on the registry nor in this workspace. That's a genuinely broken reference — a rename, a typo, a package deleted from under a dependent — and it can't be fixed by publishing harder. Verified both directions locally, since CI can't run:

• all 45 packages with @wave-av dependencies pass — no false positives
• a synthetic dependency on a package that exists nowhere is rejected by name, while its workspace sibling in the same manifest is not

I also corrected the false claim I'd written into the size-guard comment, and tightened registry_meta's slug validation — the case pattern only anchored the first character, so a name like a/../x would have reached the URL.

The pattern, since it keeps happening

Five corrections now. Every one has the same shape: a real measurement, then a conclusion about what it means that I didn't test. The numbers in this audit have held up under checking; my interpretations of them have a poor record. The thing that caught this one was trying to build the guard the claim implied — which is a decent general rule. If a finding is real, the check for it should be writable, and it should stay quiet on everything that isn't the finding. This one screamed at 45 of 49.