fix(prisma-cloud): carry the effect platform packages the alchemy CLI requires#151
Conversation
… requires The deploy path runs the alchemy CLI, whose command tree imports the Cloudflare provider namespace and platform services at load time — requiring @effect/platform-node and @effect/platform-bun. alchemy declares both as optional peerDependencies, so a package-manager install of an app depending only on @prisma/composer-prisma-cloud never installs them, and prisma-composer deploy dies before planning anything: Cannot find module "@effect/platform-node/NodeServices" from ".../node_modules/alchemy/src/Cloudflare/Workers/WorkerBridge.ts" (then the @effect/platform-bun/BunRuntime twin from Util/PlatformServices). This workspace never sees the failure because pnpm resolves the optional peers into its own tree, and any app developed inside a checkout inherits them through parent-directory module resolution — only a standalone install hits it, which is exactly the consumer this package is for. Surfaced by the open-chat port (its FRICTION.md #11), which had to declare both packages as app devDependencies to deploy at all. Declaring them as real dependencies here puts the knowledge where it belongs: this package pins alchemy exactly and always drives its CLI, so alchemy's "optional" peers are, for every consumer of this package, mandatory. Versions are the ones the workspace already resolves. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
|
Warning Review limit reached
Next review available in: 44 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: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
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 |
commit: |
…6 (D6)
Flip the database edge from plain postgres() to the contract-carrying
pnPostgres: the resource is pnPostgres({ name: "database", contract,
config }) and the service consumes pnPostgres(chatData), so the deploy
migrates the freshly provisioned database itself (a PrismaNext.Migration
resource, [database-migrate] in the plan) before the chat service starts.
The launcher reads only db.url from the { url, client } binding
(prisma/composer#154, ADR-0040) — open-chat keeps its own pg.Pool shared
with Better Auth, and the framework-built typed client is never
constructed. FRICTION.md #12's by-hand schema step is gone.
The app toolchain moves to @prisma-next 0.15 (the version the framework
bundles): contract re-emitted, migrations store regenerated as
migrations/app/20260722T1415_init/ (from: null to the re-emitted
contract's hash; the 0.13-vintage refs are deleted). Two mechanical
consequences in app code: regenerated src/prisma/contract.{json,d.ts},
and the 0.15 runtime's schema-namespaced ORM paths (db.orm.<Model> →
db.orm.public.<Model>, 32 call sites, no behavioral change).
Composer packages pin npm 0.2.0-dev.6. The @effect/platform-* dev
dependencies added as a deploy workaround are removed —
@prisma/composer-prisma-cloud carries them itself since
prisma/composer#151 (FRICTION.md #11). New FRICTION.md #13 records a bun
resolver failure when two pkg.pr.new previews reference each other,
hit while proving against the PR preview and moot on npm pins.
Deployed fresh (destroy + deploy, zero manual steps) and verified end to
end on the deploy-reported URL: [database-migrate] ran in the deploy;
shell + client asset 200; guest sign-in 200 against the brand-new
database with no schema step ever run; chat create 201 with the row in
Postgres; SSE tail ready + 4 heartbeats over ~22s; Stripe webhook 400
unsigned / 400 bad-signature / 405 GET; message generation stops at
OpenRouter's auth boundary with the placeholder key. Local dev loop
re-verified on the npm pin (shell + sign-in 200).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>
2 participants
A standalone install of an app that depends on
@prisma/composer-prisma-cloudcannot runprisma-composer deploy: the alchemy CLI's command tree imports the Cloudflare provider namespace and alchemy's platform services at load time, which require@effect/platform-nodeand@effect/platform-bun— but alchemy declares both as optional peerDependencies, so package managers skip them. The deploy dies before planning anything:then, once that package is supplied, the
@effect/platform-bun/BunRuntimetwin from alchemy'sUtil/PlatformServices.ts.This workspace never sees the failure (pnpm resolves the optional peers into its own tree), and an app developed inside a checkout inherits them via parent-directory module resolution — only a genuinely standalone install hits it, which is exactly the consumer this package exists for. Surfaced by the open-chat port (prisma/open-chat#1, its FRICTION.md #11), which had to declare both packages as app devDependencies to deploy at all.
Since this package pins
alchemyexactly and always drives its CLI, alchemy's "optional" peers are mandatory for every consumer — so this package carries them as real dependencies, pinned to the versions the workspace already resolves (@effect/platform-node@4.0.0-beta.92,@effect/platform-bun@4.0.0-beta.97). The alternative fix — alchemy lazy-importing provider namespaces so unused providers' peers stay truly optional — is upstream's to make; this closes the gap for our consumers now.After this lands, the open-chat port can drop the two
@effect/*devDependencies it added as a workaround.🤖 Generated with Claude Code