-
fix(cli): bundle @slopus/happy-wire instead of resolving it from npm
发布于
2026-08-07 04:24:03 +00:00 | 136 次提交 在此版本后已推送到 mainhappy@1.2.1-beta.0 was dead on arrival — it crashed on every invocation:
SyntaxError: The requested module '@slopus/happy-wire' does not provide an export named 'stripLeadingTaskNotificationWrappers'workspace:*publishes the local version NUMBER, never the local CODE.
@slopus/happy-wire has exactly one version on npm, 0.1.0, published
2026-02-13. Local happy-wire is still labelled 0.1.0 but carries 18
commits of drift, includingf85b20c3, which added that function and
imported it from codex/utils/sessionProtocolMapper.ts. So the CLI shipped
declaring a dependency on a tarball that predates the code it was
compiled against, and ESM failed at module load.1.2.0 survived the identical latent bug only because none of its 15
import sites needed a post-February symbol.Moving the dep to devDependencies is the fix, not a workaround: pkgroll
has no --external flag, so dependencies/peerDependencies IS its externals
policy. In devDependencies the code is inlined into dist/ and the dep
disappears from the published package.json entirely — nothing is fetched
at runtime, so nothing can drift. The label is also now accurate, since
happy-wire genuinely is build-time-only once inlined. happy-cli already
carried both of its runtime deps (zod ^4, @paralleldrive/cuid2 ^2.2.2),
so this adds nothing.No in-repo test can catch this class of bug: inside the monorepo
workspace:* resolves to local source, so prepublishOnly always sees the
correct code. Only a global install off the registry detects it.Verified against the real tarball: no import/require of @slopus/happy-wire
survives in dist/, createEnvelope and stripLeadingTaskNotificationWrappers
are defined inline, the published dependencies list drops from 36 to 35
with happy-wire absent, andhappy --versionreports 1.2.1-beta.1 from a
clean global install.Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
下载附件