Uh oh!
There was an error while loading. Please reload this page.
refactor: adopt the Prisma ORM composer API names - #72
Conversation
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (12)
Knowledge base: Disabled due to Summary by CodeRabbit
WalkthroughThe PR renames the Prisma Node.js compatibility check to ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
Composer 0.15.0 renames its ORM entrypoint (prisma/composer#265): the `/prisma-next` subpath becomes `/orm`, `pnPostgres()` becomes `postgres()`, and `pnContract()` becomes `dataContract()`. Update the scaffold templates and pin composer 0.15.0; rename the internal `supportsPrismaNext` helper to `supportsPrisma`. The Deno path deliberately keeps the `prisma-next` npm CLI (ORM-only entrypoint) and its generated `prisma-next.config.ts`/`prisma-next.md` until the consolidated CLI is Deno-compatible — those references are unchanged. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
Three fixes uncovered by the Composer-backed e2e test: - The rc.8 query builder renamed .take() to .limit(); update the postgres branch of the users template. - The rc.8 runtime generates timestamp defaults (instantNow) through the global Temporal object, which no stable Node or Bun ships. Without it the scaffolded app returns 500 on every request because the seed upsert cannot produce updatedAt. Add temporal-polyfill to postgres scaffolds and import temporal-polyfill/global in the db template. - Composer 0.16.0 pins effect 4.0.0-rc.112 exactly; move the scaffold pin and overrides from rc.111 to match. Also make the e2e endpoint probe retry: the dev CLI emits the endpoint frame before the app process has bound its port, and the first request can race the seed, so a single fetch was flaky. The MIGRATION_PATH_NOT_FOUND failures seen while debugging were environmental, not a code bug: @prisma/dev persists database state per app name under ~/Library/Application Support/prisma-dev-nodejs/, so the always-named composer-app e2e database carried a schema marker stamped by an older toolchain that the rc.8 migration graph has no path from. A clean slate needs that directory removed along with ~/.prisma-composer/emulators. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
667390e to
1414303ComparePR preview published
|
Uh oh!
There was an error while loading. Please reload this page.
Follow-on to prisma/composer#265, which retires the pre-release "Prisma Next" naming in Composer.
Changes
import { pnPostgres } from "@prisma/composer-prisma-cloud/prisma-next"→import { postgres } from "@prisma/composer-prisma-cloud/orm";pnContract()→dataContract().@prisma/composerand@prisma/composer-prisma-cloud0.14.0 → 0.16.0 (the release carrying the rename).supportsPrismaNext→supportsPrisma.Deliberately unchanged
The Deno path keeps the
prisma-nextnpm CLI (the ORM-only entrypoint) and its generatedprisma-next.config.ts/prisma-next.md, per the existing comment independencies.ts— the consolidatedprismaCLI is not yet Deno-compatible.Merge order
🤖 Generated with Claude Code