Conversation
Bun 1.3.11's bytecode generation produces broken output for our
module graph ("TypeError: Expected CommonJS module to have a function
wrapper" at runtime, reproduces natively on darwin-arm64 too). The
compile already fails with "Failed to generate bytecode for ./cli.js"
and proceeds without it, but the resulting binary still crashes at
module instantiation.
Only --minify remains. Binary size is unchanged in practice
(bytecode was being skipped after the error anyway), but now the
build succeeds cleanly and the binary runs.
Surfaced while building the v0.3.7 release.
…failure recovery
Two gaps caused the v0.3.7 release to ship an empty GitHub Release and break
install.sh for all users for ~30 min. Both are now handled in the skill:
1. Step 1.5 — mandatory pre-flight `bun build --compile` smoke test before
any user-visible step (version bump, PR, tag). Compiles the native target
only (~15-30s), runs `archon version`, greps the output for runtime-error
markers, aborts if anything fails. This would have caught both v0.3.7
bugs (the --bytecode flag producing broken bytecode, and the Pi SDK's
readFileSync of a path only present in node_modules) before the tag
was ever pushed. Escape hatch: fix the underlying bug on a feature
branch and re-run /release — no workaround to "just skip".
2. Step 10 now detects deterministic CI failure (two reruns with same
error) and jumps to a new "Recovery: deterministic release CI failure"
section instead of looping until timeout. Recovery documents:
- Delete the empty GitHub Release (keep the tag — immutability)
so releases/latest falls back to the prior working version and
install.sh stops 404-ing within seconds.
- Diagnose via `gh run view --log-failed`, with a cheat-sheet of
common failure modes (bundler bytecode, module-init crashes,
Windows timeouts).
- Cut the NEXT patch version with the fix — never reuse the broken
tag, never force-push, never upload binaries built from a
different SHA onto the original release.
- CHANGELOG note template that references the broken prior version
so the audit trail is clear for anyone inspecting tags later.
Also added two Important Rules:
- Never skip Step 1.5. The ~30s cost keeps failure modes local.
- If Step 1.5 fails, abort the release. No "skip and hope CI passes."
Skill grows from 389 → 548 lines. No changes to Steps 2–9, 11, 12.
…#1355) * fix(providers/pi): lazy-load Pi SDK to unbreak compiled archon binary Pi's @mariozechner/pi-coding-agent/dist/config.js runs `readFileSync(getPackageJsonPath(), 'utf-8')` at module top level. Inside a compiled archon binary `getPackageJsonPath()` resolves to `dirname(process.execPath) + '/package.json'`, which doesn't exist next to `/usr/local/bin/archon` — so archon crashes with ENOENT at startup before any command runs. v0.3.7's release binary build appeared to compile clean (CI fell over first on an unrelated --bytecode issue) but even the fixed-bytecode binary fails the same way locally. Convert all Pi SDK value imports and Pi-dependent helper imports to dynamic imports inside `PiProvider.sendQuery()`. Type-only imports stay static (erased by TS). Effect: registering the Pi provider and creating an instance no longer loads Pi's SDK — load happens only when a Pi workflow actually runs. Claude and Codex providers keep their static import style (their SDKs have no module-init side effects that fail in a binary); see the file header comment in provider.ts for why Pi is the deliberate outlier. Class constructors (AuthStorage, ModelRegistry, SettingsManager) are accessed via `piCodingAgent.X` rather than destructured to keep eslint's naming-convention rule happy without a disable. Add a regression test (provider-lazy-load.test.ts) that mocks @mariozechner/pi-coding-agent and @mariozechner/pi-ai, walks the same registerCommunityProviders() → getAgentProvider('pi') path the CLI and server take, and asserts neither SDK module was loaded. Runs in its own `bun test` invocation (mock.module is process-wide). Verified locally: `bun build --compile --minify --target=bun-darwin-arm64` produces a binary whose `archon version` runs cleanly and reports Build: binary, where previously every command crashed at boot. * address review: changelog, docstring, type tighten, Theme type-only import From the multi-agent review on #1355: - Add CHANGELOG.md entries under [Unreleased] ### Fixed for this PR's Pi lazy-load fix and the --bytecode removal from #1354 — both user-visible fixes (compiled binary unusable without them). - Rewrite the test-header docstring in provider-lazy-load.test.ts to describe counter-based detection instead of "mocks throw" (contradicted the actual code directly below it). - Tighten `lookupPiModel`'s first parameter from `unknown` to a local `GetModelFn` alias, moving the runtime-string cast to the single call site with a pointer to the docblock. - Update the class docblock on `PiProvider` — "v1 capabilities are all false" was stale; PI_CAPABILITIES has seven flags set to true. - `ui-context-stub.ts` imports `Theme` as a non-type value even though every usage is in a type position. Fold it into the existing `import type {…}` block so a future runtime-class `Theme` in Pi can't reintroduce an eager module load via this sibling. No behavior change. Type-check, lint, format, tests, and a local darwin-arm64 compile + version smoke all clean.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release 0.3.8
Hotfix for v0.3.7 — restore working compiled binaries. v0.3.7 was tagged but never shipped any working assets: two distinct bugs (Pi SDK's module-init
package.jsonread, and Bun--bytecodeproducing broken output for this project's module graph) made every compiled archon binary crash at startup. The v0.3.7 GitHub Release was deleted immediately (the tag remains for history); v0.3.8 is the first release with workingarchon-{darwin,linux}-{arm64,x64}andarchon-windows-x64.exebinaries since v0.3.6. Homebrew andinstall.shwere never updated to v0.3.7, so users were not exposed to the broken state.Fixed
@mariozechner/pi-coding-agent/dist/config.jsrunsreadFileSync(getPackageJsonPath(), 'utf-8')at module top-level, which inside a compiled binary resolves todirname(process.execPath) + '/package.json'— a path that doesn't exist next to/usr/local/bin/archon, making every archon command (includingarchon version) crash with ENOENT before it ran. The Pi SDK and all Pi-dependent helper modules are now dynamically imported insidePiProvider.sendQuery(). A regression test (provider-lazy-load.test.ts) walks the sameregisterCommunityProviders()+getAgentProvider('pi')path the CLI and server take and asserts neither SDK package was resolved. Claude and Codex providers keep their static import style — their SDKs have no equivalent module-init side effect. (fix(providers/pi): lazy-load Pi SDK to unbreak compiled archon binary #1355)scripts/build-binaries.shdropped the--bytecodeflag: Bun 1.3.11's bytecode step failed withFailed to generate bytecode for ./cli.jsagainst the 0.3.7 module graph and fell through to producing a binary that crashed at module instantiation with "Expected CommonJS module to have a function wrapper". Windows was already excluded; this removes the flag everywhere. Release parity preserved via--minify. (fix(build): drop --bytecode from compiled-binary build #1354)Merging this PR releases 0.3.8 to main.