fix: the framework version is a call, so a compiled binary boots - #60
Merged
Conversation
- `FRAMEWORK_VERSION` → `frameworkVersion()` (BREAKING): resolved at module scope, the read ran before `main` in every process, so `x build --target binary` shipped an artifact that threw at import. - Resolution is manifest → `ULTIMATE_FRAMEWORK_VERSION` build define → throw. A manifest that exists and declares no semver still throws `X_INVARIANT`; only a missing one falls through to the define. - `x build --target binary` passes the define; `/$bunfs` has no manifest. - `DEFAULT_SERVER_INFO` → `defaultServerInfo()` (BREAKING): a constant holding the result is the module-scope read again, one import away. - New e2e compiles a real executable and runs it, with and without the define — the gap lasted two releases because nothing ran the artifact. - Known-gap rows narrowed to what is still unproven: booting is not serving, and no scaffolded app has been run from a bare VM. Co-Authored-By: Claude <noreply@anthropic.com>
- `CLI_VERSION` → `cliVersion()` (BREAKING): the same module-scope read `frameworkVersion()` was made lazy to fix, one file over. `index.ts` re-exports `registry.ts`, so importing `@ultimat3/cli` for `runRole` alone — a compiled `apps/web/server.ts` — died on `ENOENT … '/$bunfs/package.json'` before the first role started. - `createVersionCommand` takes a resolver, so `COMMANDS` can be built at module scope without the read `x version` alone needs. - New `packages/cli/e2e/registry-boot.e2e.test.ts` compiles the registry into an executable and runs it, and compiles the module-scope read too and asserts it dies before booting — fix and defect both executable. - `@ultimat3/cli` declares `@ultimat3/schema`, which `error-catalog.ts` has always imported; tsconfig references it like every other dependent. Co-Authored-By: Claude <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (10)
📝 WalkthroughWalkthroughThe change replaces eager version constants with cached getter functions. Core version resolution now uses package manifests or a build-time define. CLI binary builds inject the define, and MCP metadata uses lazy resolution. Executable tests and documentation cover the new behavior. ChangesVersion resolution and binary boot
Estimated code review effort: 3 (Moderate) | ~20 minutes Mergeability Score: 🟡 Moderate · up to Compiled CLI binaries may still fail when users run Sequence Diagram(s)sequenceDiagram
participant x_build
participant binaryArgs
participant Bun
participant frameworkVersion
x_build->>binaryArgs: Create binary build arguments
binaryArgs->>frameworkVersion: Resolve framework version
frameworkVersion-->>binaryArgs: Return cached version
binaryArgs->>Bun: Compile with ULTIMATE_FRAMEWORK_VERSION
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/idea/17-scale-ladder.md`:
- Line 49: Update the target summary in the scale-ladder documentation to
describe static as emitting deployable files for a CDN or object store, not as a
process that starts. Keep the existing binary and bare-VM claims unchanged, and
distinguish static artifact generation from executable startup.
In `@packages/cli/e2e/registry-boot.e2e.test.ts`:
- Around line 48-63: Update the compiled-binary CLI loader and its binaryArgs()
version defines so cliVersion() receives the same fallback define used by
frameworkVersion(). Ensure the createVersionCommand(cliVersion) path returns the
defined CLI version instead of reading the unavailable manifest, without
changing cmd-help.ts.
In `@packages/core/e2e/version.e2e.test.ts`:
- Around line 37-49: Update both compileAndRun helpers in
packages/core/e2e/version.e2e.test.ts lines 37-49 and
packages/cli/e2e/registry-boot.e2e.test.ts lines 30-35 to drain build.stderr
alongside build.exited, then pass the captured diagnostic as the assertion
message while checking the exit code is zero. Alternatively, extract a shared
helper, but ensure both sites receive the same stderr-aware assertion behavior.
In `@packages/core/src/version.test.ts`:
- Around line 33-34: Update the caching test around frameworkVersion() to spy on
the filesystem read via the fs module binding, call frameworkVersion() twice,
and assert the underlying read occurs only once. Ensure version.ts performs the
read through the observable fs binding so the spy can detect repeated reads,
while preserving the existing cached string behavior.
In `@packages/core/src/version.ts`:
- Around line 61-65: Update the UltimateError construction in the version
validation path so the explanatory text is included in cause, while fix contains
only the runnable command “x build --target binary”. Preserve the existing
command text so the version-related e2e and unit assertions continue to pass.
In `@wiki/Tutorial-05-Deploy-Free.md`:
- Line 153: Update the deployment tutorial text around the x build command to
avoid hardcoding framework version 1.2.0; state that x build injects the
installed framework version via ULTIMATE_FRAMEWORK_VERSION, or use a version
placeholder consistent with the create-ultimate@1.1.0 context.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 35715e89-13a7-4864-98db-f8177a1cb95d
⛔ Files ignored due to path filters (1)
bun.lockis excluded by!**/*.lock,!**/bun.lock
📒 Files selected for processing (29)
CHANGELOG.mdCLAUDE.mdREADME.mddocs/idea/12-build-deploy.mddocs/idea/14-roadmap.mddocs/idea/17-scale-ladder.mdpackages/cli/e2e/registry-boot.e2e.test.tspackages/cli/package.jsonpackages/cli/src/cmd-build.test.tspackages/cli/src/cmd-build.tspackages/cli/src/cmd-help.tspackages/cli/src/index.tspackages/cli/src/registry.tspackages/cli/src/version-loader.test.tspackages/cli/src/workspace-checks.tspackages/cli/tsconfig.jsonpackages/core/e2e/version.e2e.test.tspackages/core/src/index.tspackages/core/src/version.test.tspackages/core/src/version.tspackages/mcp/src/dev-host.tspackages/mcp/src/index.tspackages/mcp/src/server.tspackages/mcp/src/wire.tsscripts/new-package.tswiki/CLI-Reference.mdwiki/Deployment.mdwiki/Known-Gaps.mdwiki/Tutorial-05-Deploy-Free.md
- version-loader.ts goes through resolveVersion with the same ULTIMATE_FRAMEWORK_VERSION define x build already passes, so `x --version` inside a compiled binary answers instead of throwing X_INVARIANT for a version the build knew - version.ts: fix: is a runnable command only; the prose moved into cause (axiom 4) - version.test.ts: the caching test watches the read that does not happen, not two equal strings — it can now fail - both compileAndRun helpers drain build.stderr and pass it as the assertion message; a broken compile reports a diagnostic - new e2e: the registry compiled WITH the define reports it - docs: static emits files, it does not start; the tutorial no longer hardcodes 1.2.0 Co-Authored-By: Claude <noreply@anthropic.com>
Contributor
|
Released in v1.7.1 🎉 🤖 Posted by developerz.ai — the maintainer agent, not a human. |
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.
FRAMEWORK_VERSION→frameworkVersion(),DEFAULT_SERVER_INFO→defaultServerInfo(),CLI_VERSION→cliVersion(). Read at module scope, the version resolved beforemainin every process that imported the package, sox build --target binaryshipped an artifact that threwENOENT … '/$bunfs/package.json'at import. A constant holding the result is the same read, one import away — which is why all three go.ULTIMATE_FRAMEWORK_VERSIONbuild define → throw. A missing manifest is the only absence a single-file executable makes legitimate; a manifest that exists and declares no semver is still a broken publish, stillX_INVARIANT, define or no define.x build --target binarypasses the define.packages/core/e2e/version.e2e.test.tscompiles a real executable with the define and without;packages/cli/e2e/registry-boot.e2e.test.tscompiles the command registry, boots it, and then compiles the module-scope read too and asserts that binary dies before booting — fix and defect both executable.@ultimat3/clideclares@ultimat3/schema, whicherror-catalog.tshas always imported and the workspace only hoisted. Known-gap prose narrowed to what is still unproven: booting is not serving, and no scaffolded app has been compiled and run from a bare VM.Gate:
bun run verify12/17 (5 honest skips: job, eval, drift, contract-diff, budgets); reference-app gate 10/17, 7 pinned — both baselines unchanged.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Summary by CodeRabbit
New Features
Breaking Changes
frameworkVersion(),cliVersion(), anddefaultServerInfo().Bug Fixes
Documentation