fix(cli): honor explicit --entry under auto build-type; report loaded config path#112
Conversation
… config path
Local 'app build'/'app run' with an explicit --entry and --build-type auto
silently let framework detection (e.g. Next.js) override the entrypoint,
contradicting deploy's resolution and the assertSupportedEntrypoint contract
('auto may fall back to Bun'). Resolve an explicit entrypoint to a Bun build
before detection, matching 'app deploy'.
Also report deploySettings.config.path as the compute config file in effect
whenever one loaded, even without a build block, so 'path: null' means 'no
config loaded' rather than 'no build-settings block'; status still conveys
build-block ownership.
Summary by CodeRabbit
WalkthroughThis PR updates CLI build and run resolution so an explicit ChangesCohort: Explicit entry precedence and deploy config reporting
Sequence Diagram(s)sequenceDiagram
participant runAppRun
participant resolveLocalRunFramework
participant runLocalApp
runAppRun->>resolveLocalRunFramework: entrypoint, requestedBuildType=auto
resolveLocalRunFramework->>resolveLocalRunFramework: check entrypoint and buildType
resolveLocalRunFramework-->>runAppRun: return Bun framework
runAppRun->>runLocalApp: buildType bun, entrypoint
Related PRs: None identified. Suggested labels: cli, documentation Suggested reviewers: None identified. Poem 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/cli/src/controllers/app.ts (1)
4643-4657: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winConsider covering config-declared framework interaction with the new early-return.
The new early return (
requestedBuildType === "auto" && options.entrypoint→ force"bun") runs before the branch that preserves a configured framework identity (e.g.hono) for local dev at Lines 4665-4674. Ifmerged.buildTypecan remain"auto"whilecompute.target.frameworkis set (e.g., explicit--build-type auto --entry ...alongside aprisma.compute.tsframework declaration), this would silently discard the configured framework identity in favor of a generic"bun"annotation ("set by --entry"), which changes the reportedframeworkvalue and its annotation. Worth adding a test case for this combination to confirm intended precedence (explicit--entryoverriding config framework identity, not just detection).🤖 Prompt for 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. In `@packages/cli/src/controllers/app.ts` around lines 4643 - 4657, The new early return in resolveLocalRunFramework now forces a Bun framework for any auto build with an entrypoint, which can override a config-declared framework identity from configFramework/compute.target.framework. Update the precedence logic so the explicit --entry case still respects the intended local-dev framework identity path handled later in resolveLocalRunFramework, or otherwise preserve the configured framework annotation instead of always returning frameworkFromUserFacingValue("bun", "set by --entry"). Add a test covering requestedBuildType = "auto", entrypoint set, and a declared framework (for example hono) to verify the chosen framework and annotation match the intended precedence.
🤖 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.
Outside diff comments:
In `@packages/cli/src/controllers/app.ts`:
- Around line 4643-4657: The new early return in resolveLocalRunFramework now
forces a Bun framework for any auto build with an entrypoint, which can override
a config-declared framework identity from
configFramework/compute.target.framework. Update the precedence logic so the
explicit --entry case still respects the intended local-dev framework identity
path handled later in resolveLocalRunFramework, or otherwise preserve the
configured framework annotation instead of always returning
frameworkFromUserFacingValue("bun", "set by --entry"). Add a test covering
requestedBuildType = "auto", entrypoint set, and a declared framework (for
example hono) to verify the chosen framework and annotation match the intended
precedence.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 630c2122-a23f-47f9-b937-d8946ddf6ba2
📒 Files selected for processing (6)
docs/product/command-spec.mdpackages/cli/src/controllers/app.tspackages/cli/src/lib/app/build.tspackages/cli/tests/app-build.test.tspackages/cli/tests/app-controller.test.tspackages/cli/tests/app-local-dev.test.ts
1 participant
Two reported CLI quirks turned out to be misdiagnoses of real, narrower issues. This fixes the real ones.
What was reported vs. what's actually true
"
prisma.compute.tsnever loads (config.path: nullwherever I put it)" — the config does load; its framework/app/region/env flow through and are visible indeploySettings.framework.source(set by prisma.compute.ts). The misleading part:deploySettings.config.pathwasnullwhenever the config had nobuildblock, because that field tracked the build-settings block, not "was a config in effect.""
--framework/--entryare silently ignored when a framework is detected from deps" — false forapp deploy, which resolves--framework→--entry→ detection (flags win). The real bug is in localapp build/app run: an explicit--entryunder--build-type autowas silently overridden by framework detection (e.g. Next.js), even thoughassertSupportedEntrypointdocuments "auto may fall back to Bun" and deploy already resolves--entryto a Bun build.Changes
1. Honor explicit
--entryunderauto(build + run).resolveAppBuildStrategy(the singleapp buildchokepoint) andresolveLocalRunFramework(app run) now resolve an explicit entrypoint to a Bun build before framework auto-detection, matching howapp deployresolves--entry.app deployis unaffected (it always passes a concrete build type, neverauto).2. Report the loaded config path in deploy output.
deploySettings.config.pathnow reports the compute config file in effect whenever one loaded, even without abuildblock.path: nullnow means "no config loaded" rather than "no build block";statusstill distinguishes whether the build block owned the build settings ("config") or they were inferred ("inferred").Testing
resolveAppBuildStrategyresolves an explicit entrypoint to Bun even when Next.js is detectable (resolution-level, no build execution).app runresolves an explicit entrypoint to Bun even when Next.js is detectable (asserts the local runner is invoked withbuildType: "bun").deploySettings.config={ path: "prisma.compute.ts", status: "inferred" }for a loaded config with no build block.tscclean; spec (command-spec.md) updated for build, run, and deploy output.