Tags: prisma/orm
Tags
chore(release): bump to 8.0.0-rc.11 (#30272) ## Release: 8.0.0-rc.10 → 8.0.0-rc.11 This is the routine release PR per [docs/oss/versioning.md](https://github.com/prisma/prisma/blob/main/docs/oss/versioning.md). It bumps every workspace package to 8.0.0-rc.11 and moves every `@prisma/cli-engine` pin from 0.3.0 to 0.4.0. No other change has merged since rc.10; the engine move is the whole release. The engine change: `@prisma/[email protected]` adds a `--format markdown` output format to every command and widens the engine's `Format` type from `"human" | "json"` to `"human" | "json" | "markdown"` ([prisma/prisma-cli#260](prisma/prisma-cli#260)). No other public API changed. `@prisma/orm-toolchain` peers the engine at an exact version, so the toolchain has to republish to run under a host CLI on 0.4.0. The lockfile change is exactly the engine resolution (0.3.0 → 0.4.0, same peers) plus the routine `workspace:` specifier bumps. Review surface: [docs/releases/v8.0.0-rc.11.md](https://github.com/prisma/prisma/blob/release/8.0.0-rc.11/docs/releases/v8.0.0-rc.11.md) is the release notes file that becomes the GitHub Release body. The matching `CHANGELOG.md` entry and the `8.0.0-rc.10-to-8.0.0-rc.11` upgrade recipes (app and extension) are included; `check:upgrade-coverage` requires the recipes because the bump touches `examples/` and `packages/3-extensions/`. The supabase contract fixtures carry the new version stamp, as in every release. **Merging this PR ships the release**: the push to `main` carries the bumped root `version`, the `Publish to npm` workflow detects the change and publishes 8.0.0-rc.11 under `latest`, creates a pre-release GitHub Release from the notes file, then publishes `8.0.0-rc.11-dev.1` under `dev`. Local verification: `check:release-notes` (PR mode), `check:upgrade-coverage`, and `test:scripts` (507 tests) pass; the CLI tooling package's typecheck and its 1455 tests pass against engine 0.4.0. `fixtures:check` passes against a local Postgres (the emitted contracts are unchanged apart from the version stamp). 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * CLI commands now support Markdown output through `--format markdown`, alongside human-readable and JSON formats. * **Breaking Changes** * The CLI engine requirement is updated to version 0.4.0. * **Documentation** * Added release notes and upgrade guidance for applications and extensions, including refreshed generated contract metadata. * **Release Updates** * Updated Prisma 8 packages, examples, fixtures, and tooling to version 8.0.0-rc.11. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
docs(skills): the release cut also prepares the prisma/web docs PR an… …d the Supabase fixture re-emit (#30271) ## At a glance Cutting rc.10 took two extra commits and a docs-site PR that the release skill did not mention. The skill now describes all three, so the next release cut produces them without rediscovery: ```text 1. chore(release): bump to <version> 2. chore(release): re-emit the Supabase fixtures + upgrade-recipe declaration ← CI fails without this 3. docs(release): release notes ← already covered 4. prisma/web PR: docs(docs): update the Prisma ORM 8 pages for <version> ← new step 10 ``` ## What changed in the skill - **Step 5 (sanity-check)** now says that the Supabase extension stamps its version into eight emitted fixture files, that the `Fixtures` job diffs them, and that `check:upgrade-coverage` then requires the bump PR to declare the re-emit in the app upgrade recipe. The rc.9 and rc.10 bumps both needed exactly this. - **New step 10** prepares the prisma/web docs PR from the release notes: clone into a gitignored path in the release worktree, move the version numbers on the three pages that carry them, walk the notes entry by entry to find the pages that state old behaviour (with the usual home for each kind of change), run the three docs linters, and open the PR with a body that says it merges only after the publish. This is the process rc.10 followed in prisma/web#8261. - **Step 11 (report)** reports both PRs. It also records the merge order if the maintainer asks the agent to merge, and two merge-queue facts that cost time on rc.10: the queue refuses a PR with any unresolved review thread even when checks are green, and CodeRabbit flags the tag-pinned recipe links as dead every time, which is expected because the publish creates the tag. - The frontmatter description mentions the docs-site PR so the skill triggers with that expectation. ## Validation `pnpm lint:skills` passes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the npm release workflow to include required version updates across Supabase contract and fixture files. - Added upgrade-coverage instructions for re-emitting the Supabase extension version. - Added steps to prepare a matching Prisma documentation-site pull request with updated version tables and release notes. - Clarified reporting, pull request linking, worktree details, and the required release-first merge order. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
chore(release): bump to 8.0.0-rc.11 (#30272) ## Release: 8.0.0-rc.10 → 8.0.0-rc.11 This is the routine release PR per [docs/oss/versioning.md](https://github.com/prisma/prisma/blob/main/docs/oss/versioning.md). It bumps every workspace package to 8.0.0-rc.11 and moves every `@prisma/cli-engine` pin from 0.3.0 to 0.4.0. No other change has merged since rc.10; the engine move is the whole release. The engine change: `@prisma/[email protected]` adds a `--format markdown` output format to every command and widens the engine's `Format` type from `"human" | "json"` to `"human" | "json" | "markdown"` ([prisma/prisma-cli#260](prisma/prisma-cli#260)). No other public API changed. `@prisma/orm-toolchain` peers the engine at an exact version, so the toolchain has to republish to run under a host CLI on 0.4.0. The lockfile change is exactly the engine resolution (0.3.0 → 0.4.0, same peers) plus the routine `workspace:` specifier bumps. Review surface: [docs/releases/v8.0.0-rc.11.md](https://github.com/prisma/prisma/blob/release/8.0.0-rc.11/docs/releases/v8.0.0-rc.11.md) is the release notes file that becomes the GitHub Release body. The matching `CHANGELOG.md` entry and the `8.0.0-rc.10-to-8.0.0-rc.11` upgrade recipes (app and extension) are included; `check:upgrade-coverage` requires the recipes because the bump touches `examples/` and `packages/3-extensions/`. The supabase contract fixtures carry the new version stamp, as in every release. **Merging this PR ships the release**: the push to `main` carries the bumped root `version`, the `Publish to npm` workflow detects the change and publishes 8.0.0-rc.11 under `latest`, creates a pre-release GitHub Release from the notes file, then publishes `8.0.0-rc.11-dev.1` under `dev`. Local verification: `check:release-notes` (PR mode), `check:upgrade-coverage`, and `test:scripts` (507 tests) pass; the CLI tooling package's typecheck and its 1455 tests pass against engine 0.4.0. `fixtures:check` passes against a local Postgres (the emitted contracts are unchanged apart from the version stamp). 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * CLI commands now support Markdown output through `--format markdown`, alongside human-readable and JSON formats. * **Breaking Changes** * The CLI engine requirement is updated to version 0.4.0. * **Documentation** * Added release notes and upgrade guidance for applications and extensions, including refreshed generated contract metadata. * **Release Updates** * Updated Prisma 8 packages, examples, fixtures, and tooling to version 8.0.0-rc.11. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
chore(release): bump to 8.0.0-rc.10 (#30268) `8.0.0-rc.9` → `8.0.0-rc.10`. ## What ships The user-facing changes are in [`docs/releases/v8.0.0-rc.10.md`](docs/releases/v8.0.0-rc.10.md), mirrored into `CHANGELOG.md`. Review that file as the release's public statement. In short: the Prisma 8 rename reaches every identifier a project can see (schema header, environment variables, config directory, primer file), the emitted contract gains `Models`, `Scalars`, `Shape`, and a working `ResultType` on ORM queries, `db sign` sets the `db` ref so the first plan after adoption stays incremental, and the language server completes attribute names. ## Skill audit I checked the bundled `prisma-8` skill against every PR in the range. The in-range PRs had already updated the references for `db sign` ref advancement and its two flags (#30251), the rename (#30262), the `Models` and `Shape` types (#30231), and the rc.9-to-rc.10 upgrade recipes for both audiences. Two gaps are fixed in the second commit: the skill date stamp, and `references/contract.md` never mentioned the `// use prisma-8` schema header at all. `library_version` was stamped to rc.10 by `pnpm bump-version`. ## Merging this PR ships the release The push to `main` carries the bumped root `version`. The `Publish to npm` workflow publishes `8.0.0-rc.10` under the `latest` dist-tag and creates a matching pre-release GitHub Release whose body is the notes file above. See [`docs/oss/versioning.md`](docs/oss/versioning.md). A matching prisma/web PR updates the docs site for this release and should merge once this one is published. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added named model and result types for contracts. * Added language-server completion for attributes and named arguments. * Added nullable metadata and validation for to-one relations. * Added reference-selection controls and JSON metadata to `db sign`; the `db` reference now advances by default. * **Bug Fixes** * Improved migration planning and PostgreSQL connection handling. * Corrected package tag handling in `orm init`. * **Documentation** * Documented Prisma 8 schema headers, renamed CLI environment variables, and updated upgrade guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
chore(release): bump to 8.0.0-rc.10 (#30268) `8.0.0-rc.9` → `8.0.0-rc.10`. ## What ships The user-facing changes are in [`docs/releases/v8.0.0-rc.10.md`](docs/releases/v8.0.0-rc.10.md), mirrored into `CHANGELOG.md`. Review that file as the release's public statement. In short: the Prisma 8 rename reaches every identifier a project can see (schema header, environment variables, config directory, primer file), the emitted contract gains `Models`, `Scalars`, `Shape`, and a working `ResultType` on ORM queries, `db sign` sets the `db` ref so the first plan after adoption stays incremental, and the language server completes attribute names. ## Skill audit I checked the bundled `prisma-8` skill against every PR in the range. The in-range PRs had already updated the references for `db sign` ref advancement and its two flags (#30251), the rename (#30262), the `Models` and `Shape` types (#30231), and the rc.9-to-rc.10 upgrade recipes for both audiences. Two gaps are fixed in the second commit: the skill date stamp, and `references/contract.md` never mentioned the `// use prisma-8` schema header at all. `library_version` was stamped to rc.10 by `pnpm bump-version`. ## Merging this PR ships the release The push to `main` carries the bumped root `version`. The `Publish to npm` workflow publishes `8.0.0-rc.10` under the `latest` dist-tag and creates a matching pre-release GitHub Release whose body is the notes file above. See [`docs/oss/versioning.md`](docs/oss/versioning.md). A matching prisma/web PR updates the docs site for this release and should merge once this one is published. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added named model and result types for contracts. * Added language-server completion for attributes and named arguments. * Added nullable metadata and validation for to-one relations. * Added reference-selection controls and JSON metadata to `db sign`; the `db` reference now advances by default. * **Bug Fixes** * Improved migration planning and PostgreSQL connection handling. * Corrected package tag handling in `orm init`. * **Documentation** * Documented Prisma 8 schema headers, renamed CLI environment variables, and updated upgrade guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
fix(cli): after db sign, migration plan proposes only the change inst… …ead of every table (#30251) ## At a glance Bringing an existing database under Prisma 8, then making a first schema change: ```bash prisma contract infer --db "$DATABASE_URL" --output prisma/contract.prisma prisma contract emit prisma db sign --db "$DATABASE_URL" # add a column to the contract prisma contract emit prisma migration plan --name add-users-email ``` Before this PR, the last command proposed creating every table in the database: ``` ✔ Planned 12 operation(s) from: (baseline) to: 4f1c… ``` After it, the plan contains only the change: ``` ✔ Planned baseline + 1 operation(s) from: 9a72… ← the contract db sign recorded to: 4f1c… ``` ## The decision `db sign` now sets the `db` ref, the same way `db init` and `db update` already do. Unlike those two commands, passing `--db <url>` does not turn this off, because adoption is almost always done against the real database via `--db`. A new `--no-advance-ref` flag is the explicit opt-out for pipelines. ## How `migration plan` decides where to start The planner has to be told which contract the database is currently at. It resolves that origin in a fixed order: `--from` if given, else the `db` ref (a committed file at `migrations/app/refs/db.json` that points at a contract snapshot), else the empty contract. When the origin is the `db` ref and no migrations exist on disk yet, the planner already knows how to produce a baseline package (`null → ref`) plus the delta (`ref → contract`) in one run. That is the auto-baseline path, and it is what makes `db init`, edit, `db update`, edit, `migration plan` work today. ## Why adoption broke `db sign` verified the live schema against the contract and wrote the database marker, but it never wrote the `db` ref. So for an adopting user the planner fell through to the empty contract. The refusal that exists for "no ref but migrations already on disk" (`MIGRATION.PLAN_ORIGIN_UNKNOWN`) did not fire, because an adopting user has no migrations yet. The result was a silent full-recreate plan. Two users hit it in one week and asked what `--from` was for. The upgrade guide worked around it with three extra commands (`migration plan --name baseline`, `db sign`, `migration ref set db <dir>`); the "add to existing project" page taught none of them. ## What `db sign` does now After `client.sign` succeeds, the command writes the signed contract into the snapshot store and points the `db` ref at it (`packages/1-framework/3-tooling/cli/src/orm/db/sign.ts`, via the existing `advanceRefSafely`). Specifically: - The hash and artifacts are those of the contract actually signed: the emitted contract, or the resolved snapshot when a contract reference is passed (`db sign production --db $URL`). - Re-signing at a newer hash moves the ref. An existing ref pointing elsewhere is overwritten, and the human output shows the previous hash. - `--advance-ref <name>` redirects the write to another ref. `--no-advance-ref` skips it. Both together are refused before any database connection with `CLI.ADVANCE_REF_ARG_CONFLICT`. - JSON output gains `advancedRef: { name, hash }`, or `null` when skipped. - No migration package is written at sign time. The planner's auto-baseline handles the empty-graph case. Over a non-empty graph, a signed hash that is not a graph node makes the next default plan refuse with `MIGRATION.HASH_NOT_IN_GRAPH`, exactly as it does after `db update`. Two hardening changes fell out of review. `advanceRefSafely` (`control-api/operations/ref-advancement.ts`) now reads the contract `.d.ts` inside its structured-error path, so a missing `.d.ts` surfaces as `CLI.FILE_NOT_FOUND` with a `contract emit` fix rather than an opaque error after the marker is already written. And sign reads only the ref it is about to advance, so a corrupt unrelated ref file cannot fail a completed signature. ## `migration plan` names its fallback With no `--from`, no `db` ref, and no migrations, the plan still starts from the empty contract. That is the intended first plan in a deploy-first project, so it is not refused. It now prints one muted line under the summary: ``` No db ref set — planning from an empty database. Run db init, db update, or db sign if a database already exists. ``` JSON gains `fromDefaulted: true` in that case only. An explicit `--from @empty` prints nothing. ## Tests `test/integration/test/cli.db-sign-ref-advancement.e2e.test.ts` runs the adoption flow above against Postgres and asserts the plan's `from` is the signed hash and its operations exclude the pre-existing tables. Further cases cover `--db`, `migration status` after signing (current equals target, nothing pending), re-sign, `--advance-ref`, `--no-advance-ref`, and a refused signature writing nothing. The Mongo sign test asserts the ref too. CLI unit tests are split into `db-sign.test.ts` and `db-sign.ref-advancement.test.ts` with a shared fixture module; the contract-reference test deletes the emitted `.d.ts` first so it fails if sign ever used the emitted contract instead of the resolved one. ## Docs The shipped skill (`skills/prisma-8/references/migration-model.md`, `quickstart.md`, `migrations.md`, `debug.md`) describes the new adoption sequence and lists sign in the "who advances refs" table with both flags. `docs/glossary.md`, the migration subsystem doc, the migration domain design docs, and ADR 218 (as an amendment) list `db sign` among the ref writers. The `db sign` entry in `docs/CLI Style Guide.md` is rewritten; it previously listed five flags that never existed. The docs site is handled separately. The "add to existing project" page can drop the three-command workaround and teach the sequence at the top of this description. Release notes for the next RC should list this under Fixes; there is no consumer code change, so no upgrade entry is needed. ## Alternatives considered - **Keep the `db init` / `db update` rule that `--db` suppresses the ref write, and teach `db sign --db $URL --advance-ref db`.** Uniform across commands, but it reintroduces the one extra flag the change exists to remove, on the path every adopting user takes. Rejected; `--no-advance-ref` gives pipelines the same opt-out explicitly. - **Write a baseline migration package at sign time.** Unnecessary: the planner's auto-baseline already produces it on the first plan, and writing packages from a verify command would blur what sign is. - **Refuse the silent greenfield plan the way `PLAN_ORIGIN_UNKNOWN` does when migrations exist.** That would break the intended first plan in deploy-first projects. A notice costs nothing and covers the "never ran init, update, or sign" case. - **Refuse when the `db` ref already points elsewhere.** `db update` overwrites without complaint, and the skill already tells users to expect that. Showing the previous hash is enough. ## Follow-up `db init`, `db update`, and `migrate --advance-ref` still read the contract `.d.ts` outside the guarded path and keep the opaque-error failure mode this PR fixes for sign. Tracked separately. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - `db sign` now advances the `db` ref by default and stores a snapshot. - Added `--no-advance-ref` to sign without updating refs or snapshots. - Added `--advance-ref <name>` to target a specific ref. - Migration plans now indicate when their origin defaults to an empty database. - **Bug Fixes** - Improved validation and error reporting for conflicting ref options and missing contract files. - Greenfield planning now correctly handles empty versus non-empty migration graphs. - Explicit database targets now suppress implicit ref advancement for `db init` and `db update`. - **Documentation** - Updated migration workflows, adoption guidance, ref advancement rules, and CLI error references. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
Conform the prisma-8 skill to the skill-authoring guidelines (pre-con… …ditions, trigger-only description, dead links) (#30264) ## Linked issue n/a — follow-up to #30250 (the rc.9 fact refresh); no Linear ticket. ## Skill update This PR is a skill update: structural conformance of `skills/prisma-8/` with the internal skill-authoring guidelines. No public surface changes. ## At a glance The routing file now opens with pre-conditions an agent must check before acting: ```markdown ## Pre-conditions 1. **The project is on Prisma 8.** `prisma.config.ts` exports `definePrismaConfig({ orm: ... })`, and `package.json` depends on `@prisma/orm-postgres`, `@prisma/orm-sqlite`, or `@prisma/orm-mongo`. A project with `schema.prisma` and `@prisma/client` is Prisma 7 or earlier; this skill does not apply. 2. **The skill matches the installed version.** Compare `metadata.library_version` with the installed `@prisma/orm-*` version. If they differ, run `prisma skills sync` and re-read this file. 3. **The contract artefacts exist.** `contract.json` and `contract.d.ts` sit next to the contract source; if missing or stale, run `prisma contract emit` first. ``` Before, the frontmatter description was a capability summary and the file had no pre-conditions. ## Summary The guidelines ask for trigger-only descriptions, a dated `metadata.version`, a pre-conditions section, no tool names, and relative links that resolve. The skill failed five of those checks; this PR fixes them without touching the verified facts landed in #30250. ## Decision Ship the structural fixes only: 1. `description` rewritten as "Use when …" trigger phrases (870 chars, under the 1024 lint cap). 2. `metadata.version: '2026-09-11'` added; the prepack stamper rewrites only `library` / `library_version` and leaves it intact. 3. `## Pre-conditions` added to `SKILL.md`. 4. Nine `../../docs/…` links in `migrations.md` / `migration-review.md` repointed at GitHub — inside the published tarball there is no `docs/` directory, so they resolved nowhere. 5. The one tool-name reference ("ripgrep") removed. 6. `queries-postgres.md` states that `.some()` / `.none()` / `.every()` take an optional predicate, a gap the behavioral validation surfaced. ## Reviewer notes - **Imperative voice is not done.** The references open most workflows with "The concept: …" prose. Converting ~3,900 lines of freshly verified content is a separate per-file pass with re-verification; it is called out in the commit body rather than attempted here. - **Behavioral validation** (the guidelines' step 8) was run: a fresh agent, ten realistic Prisma 8 tasks, forbidden from reading anything but the skill. Without the skill 8/10 answers were wrong (invented APIs such as `db.sql.insert("user").values(...)`, `--allow-destructive`, `@prisma/orm-postgres/lints`); with the skill 10/10 matched the verified facts. The two loopholes it flagged are closed (the import-path mapping in #30250, the optional predicate here). - Ephemeral-marker rules do not apply: the skill produces code, not review artifacts. ## Testing performed - `pnpm lint:skills` passes. - `stampSkillMetadata` from `scripts/set-version-utils.ts` exercised against the new frontmatter to confirm the extra key survives stamping. - Behavioral validation as described above (scratch answer files, not committed). ## Alternatives considered - **Rewrite the reference bodies into imperatives in the same PR.** Rejected: it would churn every line of content that was just verified and reviewed, and mistakes in that rewrite would be hard to spot under the structural diff. - **Keep repo-relative doc links and rely on readers having the monorepo.** Rejected: the skill ships in the npm tarball, where those paths are dead. ## Checklist - [x] All commits are signed off (`git commit -s`) per the [DCO](../CONTRIBUTING.md#developer-certificate-of-origin-dco). - [x] I read [CONTRIBUTING.md](../CONTRIBUTING.md) and the change is scoped to one logical concern. - [x] Tests are updated (n/a — doc-only skill content). - [ ] The PR title is in `TML-NNNN: <sentence-case title>` form — no Linear ticket exists; retitle once one is filed. - [x] The **Skill update** section above is filled in. ## Notes for the reviewer See *Reviewer notes* above. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified Prisma 8 guidance, including supported signals, required configuration, dependency versions, and artifact prerequisites. - Updated documentation links for more reliable navigation. - Clarified relation predicate requirements: `.some()` and `.none()` may omit predicates, while `.every()` requires one. - Refined runtime guidance to avoid assumptions about unsupported configuration keys. - Added a publication version to the Prisma 8 skill metadata. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
docs(changelog): describe the file as the Prisma 8 release index (#30265 ) One line: the changelog intro still called itself the index of "Prisma Next" releases. The legacy-name lint exempts `CHANGELOG.md` as a dated record, which is right for the entries but let this live sentence slip past the rename in #30248 and #30262. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the changelog to reference Prisma 8 releases instead of Prisma Next releases. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
refactor: rename every user-facing prisma-next identifier to Prisma 8 (… …#30262) ## Linked issue n/a — no Linear ticket. Completes the rename that #30248 started for prose; builds on #30261. ## At a glance Every `prisma-next` identifier a user can see is renamed. Before and after, for a scaffolded project: ```text // use prisma-next → // use prisma-8 (schema header) prisma-next.md → prisma-8.md (primer at the project root) PRISMA_NEXT_DISABLE_TELEMETRY → PRISMA_DISABLE_TELEMETRY (and every other PRISMA_NEXT_* variable) ~/.config/prisma-next/ → ~/.config/prisma-8/ (per-user telemetry config) prisma-next contract emit → prisma contract emit (CLI invocations in docs, fixtures, recordings) ``` ## Summary After #30248 the product was called Prisma 8 in prose, but the working name was still written into user projects and printed by the CLI: the schema header, the primer file, the environment variables, the per-user config directory, the language-server diagnostic source, the Standard Schema vendor string, the contract brand symbol, the advisory-lock domain, and about 650 fixture and doc files that spelled out `prisma-next …` commands. This PR renames all of it in one pass and tightens the legacy-name lint so the only occurrences left are the ones with a reason. ## Decision One commit. The mapping: | Surface | Before | After | |---|---|---| | Schema header | `// use prisma-next` | `// use prisma-8` | | Primer file `init` writes | `prisma-next.md` | `prisma-8.md` | | CLI environment variables | `PRISMA_NEXT_*` | `PRISMA_*` | | Per-user config directory | `prisma-next/` | `prisma-8/` | | Language-server diagnostic source | `prisma-next` | `prisma` | | Standard Schema vendor, VS Code publisher | `prisma-next` | `prisma` | | Contract brand symbol | `__prisma_next_brand__` | `__prisma_8_brand__` | | Postgres advisory-lock domain | `prisma_next.contract.marker` | `prisma_8.contract.marker` | | Example database names | `prisma_next_*` | `prisma_8_*` | | README banner image | `images/prisma-next.png` | `images/prisma-8.png` | | Telemetry docs URL | `prisma-next.dev/docs/…` | `www.prisma.io/docs/…` | | New-issue links | `github.com/prisma/prisma-next/issues/new` | `github.com/prisma/orm/issues/new` | | CLI invocations in prose, fixtures, and recordings | `prisma-next db verify` | `prisma db verify` | `prisma-8` is the slug the repo already uses for the skill, the examples, and the upgrade directories, so it is the slug for everything that needs one. Environment variables drop the infix entirely because `PRISMA_*` is what users expect and nothing else in the repo claims those names. What keeps the old name, each with a lint allowance that says why: - **Dated records**: changelog, release notes, ADRs, shipped upgrade instructions, gotcha logs, the framework-gaps review, and the `projects/` and `drive/` write-ups. - **Pinned links** into the old repository by number, Linear slugs, and links to ADRs whose filenames carry the name. - **`@cipherstash/prisma-next`**, a third party's published package name. - **Retirement proofs**: the list of old skill directories `init` deletes, and the tests asserting that no `prisma-next` bin or skill directory is installed any more. ## Behavior changes & evidence - **Schema header.** The inferred-schema printer and the `init` templates write `// use prisma-8`. The language server accepts both headers, so existing schemas keep their diagnostics and completion, and its Format action rewrites the old header to the new one. [packages/1-framework/3-tooling/language-server/src/schema-directive.ts](packages/1-framework/3-tooling/language-server/src/schema-directive.ts), [packages/1-framework/2-authoring/psl-printer/src/ast-to-print-document.ts](packages/1-framework/2-authoring/psl-printer/src/ast-to-print-document.ts). Evidence: the `renameLegacyDirective` tests, the server test that formats a legacy-headed schema, and the psl-printer tests. - **Environment variables.** Telemetry gating, the endpoint override, and the debug switch read the new names. `PRISMA_NEXT_DISABLE_TELEMETRY` is still honoured as an opt-out so nobody is silently opted back in; the endpoint and debug spellings are not. [packages/1-framework/3-tooling/cli-telemetry/src/gating.ts](packages/1-framework/3-tooling/cli-telemetry/src/gating.ts). Evidence: cli-telemetry gating tests. - **Per-user config directory.** [packages/1-framework/3-tooling/cli-telemetry/src/user-config.ts](packages/1-framework/3-tooling/cli-telemetry/src/user-config.ts). Existing users see the telemetry consent prompt once more; nothing else is lost. - **Primer file.** [packages/1-framework/3-tooling/cli/src/orm/init-scaffold.ts](packages/1-framework/3-tooling/cli/src/orm/init-scaffold.ts). Evidence: init-scaffold tests and template snapshots. - **Advisory-lock domain.** A CLI on this version and one on the previous version take different locks for the same marker. Both versions running migrations against one database at the same moment is already unsupported. - **Upgrade instructions.** Entries for the header, the environment variables, and the primer file are recorded in the rc.9 → rc.10 app and extension instructions with detection patterns, so the published upgrade skill applies the rename. ## Testing performed - `pnpm test` in cli (1437), cli-telemetry (112), language-server (312), psl-printer (63), framework-components (672), target-postgres (1607), vite-plugin-contract-emit (31), emitter (231), and `pnpm test:scripts` (507): all pass after `pnpm build`. The language-server tests hard-coded the old header's length in semantic-token arrays and span offsets; those expectations are updated. - Committed migration steps and their content-addressed contract snapshots are left untouched, since rewriting them would break their hashes; the lint treats them as dated records. - `pnpm lint:legacy-name` passes with the tightened allowances; `node --test scripts/lint-legacy-name.test.mjs` passes (14 tests, including new negative cases for the header, primer, and skill names). - `pnpm check:upgrade-coverage --mode pr --prev origin/main` passes. ## Skill update `skills/prisma-8` references and the two rc.9 → rc.10 upgrade instruction files are updated in this PR. ## Checklist - [x] All commits are signed off (`git commit -s`) per the [DCO](../CONTRIBUTING.md#developer-certificate-of-origin-dco). - [x] I read [CONTRIBUTING.md](../CONTRIBUTING.md) and the change is scoped to one logical concern. - [x] Tests are updated. - [ ] The PR title is in `TML-NNNN: <sentence-case title>` form. No Linear ticket exists for this change. - [x] The **Skill update** section above is filled in. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
Bring the prisma-8 agent skill up to rc.9 (21 verified defects + name… …space-keyed samples) (#30250) ## Linked issue n/a — no Linear ticket for this pass; the brief was a written review of `skills/prisma-8/references/*.md` against the rc.9 tag. ## Skill update This PR *is* the skill update: every reference file under `skills/prisma-8/` is re-verified against `packages/`, `docs/releases/`, and `examples/` at rc.9. No public surface changes. ## At a glance Before this PR the skill taught an agent to read rows like this: ```typescript const plan = db.sql.user.insert({ email }).returning('id', 'email').build(); const [row] = await db.runtime().execute(plan); ``` Since rc.2 that resolves `{ affectedRows }`, not rows, and on the Postgres façade `db.sql.user` is a type error. The skill now teaches what `examples/prisma-8-demo/src/queries/dml-operations.ts` does: ```typescript const plan = db.sql.public.user.insert([{ email }]).returning('id', 'email').build(); const [row] = await db.runtime().query(plan); ``` ## Summary The `prisma-8` skill ships inside the `@prisma/orm-*` tarballs and is what coding agents read instead of the docs site, so every stale line is an agent writing broken code into a user's project. Twenty-one defects were identified against the rc.9 tag; this PR fixes them plus four more classes found in the full pass, without changing the skill's structure or voice. ## Decision This PR ships a fact-only refresh of `skills/prisma-8/SKILL.md`, its twelve `references/*.md` files, and three journey-test checklists. The commit body lists the source line used for each of the 21 items. The headline corrections: 1. **Rows come from `runtime.query()`; `execute()` resolves `{ affectedRows }`** and throws `RUNTIME.MONGO_STATISTICS_UNSUPPORTED` on a Mongo find/aggregate. Every Postgres, Mongo, and Supabase sample that read rows through `execute` is rewritten. 2. **Every `PN-*` error code is replaced by its dotted name** (`MIGRATION.UNFILLED_PLACEHOLDER`, `CONTRACT.MARKER_MISMATCH`, `CONFIG.MISSING_EXTENSION_PACKS`, …), the `debug.md` routing table is rebuilt from `docs/reference/error-reference.md`, and the exit-code semantics (`2` could not run, `4` ran and found something) are stated. 3. **`prisma.config.ts` is the envelope** `definePrismaConfig({ orm: ormConfig({...}) })`; the flat `defineConfig` form (and the eight-import low-level Supabase config) is gone. 4. **`orm init` facts**: default schema path `src/prisma/contract.prisma`, no `--skip-skills`, no skill install, the retired `prisma-cli` binary replaced by `prisma`, and the TML-2532 "init scaffolds the wrong layout" notes removed. 5. **Migration authoring**: operations are `Migration` base-class methods with object arguments (`this.addColumn({ schema, table, column: col(...) })`), one `BEGIN`/`COMMIT` per `db migrate` run, the marker is `prisma_contract.marker`, destructive consent is the database name or `--confirm <database>` (never `-y`), `migration show` takes a required positional, and `migration plan --from` resolves only `@empty` of the reserved forms. 6. **Things that exist and were documented as gaps**: many-to-many `include` and nested `create`/`connect`, `and`/`or`/`not` on `@prisma/orm-postgres/orm-client`, `db.prepare` / `ps.query`, Mongo PSL `@@discriminator`/`@@base`, scalar lists on PostgreSQL, the cache middleware, and lints/budgets on `@prisma/orm-postgres/family-runtime`. Things documented that don't exist: `@internal/middleware-telemetry`, a collection-level `.count()`, the cipherstash extension. 7. **Streaming stated exactly**: `for await` decodes per row everywhere, but the long-lived `postgres()` façade runs with cursors disabled, so the raw result is fetched in full; only the serverless façade reads through a cursor (batches of 100). 8. **Temporal floor**: Node.js 26.8.2+ ships `globalThis.Temporal`; earlier Node needs `temporal-polyfill/full/global` or the `*String` column types. Added to `contract.md` and the `debug.md` routing table. Found in the pass, beyond the brief: - **The Postgres façade has no flat `db.orm.User` / `db.sql.user`.** Both surfaces are keyed by storage namespace; the skill used the flat form in ~60 samples and claimed it "still works when names are unique". All Postgres samples now use `db.orm.public.User` / `db.sql.public.user`, with the SQLite (unbound namespace, flat) and Mongo (collection name) rules stated beside them. - **`migration status` codes that don't exist** (`MIGRATION.UP_TO_DATE`, `DATABASE_BEHIND`, `NO_MARKER`, `DIVERGED`, `CONTRACT.AHEAD`) replaced by the three findings it actually emits plus the `--json` document fields that carry the other states. - Mongo helper imports moved to the public `@prisma/orm-mongo/query-builder` and `query-ast/execution` subpaths. ## Reviewer notes - **Import-path convention.** The skill's deliberate `@internal/postgres/*` spellings are kept (users read them as `@prisma/orm-postgres/*`). Where the internal façade lacks the subpath (`orm-client`, `family-runtime`, Mongo `target/migration`) the public `@prisma/orm-*` path is written, matching the demos. - **The `migration.ts` data-transform sample** shows `postgres<End>({ contractJson: endContract })` and passes its `.contract` to `this.dataTransform`. The rendered scaffold passes the raw JSON import, which does not satisfy `Contract<SqlStorage>` under `tsc` (it runs fine under node). That is a scaffold rough edge outside this PR; the skill shows the route that typechecks. - **Journey tests** under `skills/journey-tests/` are manual Markdown checklists, so "pass" is not automatable. Three had stale content (a `PN-MIG-2042` code, `schema.psl` / `prisma/contract.ts` paths) and were updated. - **`PN-UPGRADE-NNNN`** in `upgrade-app.md` / `upgrade-extension.md` is left alone: it is a code the skill tells the agent to emit for its own upgrade procedure, not a framework code. - **Largest diff** is `queries-postgres.md` (the namespace rewrite touches most samples) and `debug.md` (routing table rebuilt). Spot-check those two against `examples/prisma-8-demo/src` and `docs/reference/error-reference.md`. ## Behavior changes & evidence - Row reads and non-returning writes use the right runtime method in [queries-postgres.md](skills/prisma-8/references/queries-postgres.md), [queries-mongo.md](skills/prisma-8/references/queries-mongo.md), [supabase.md](skills/prisma-8/references/supabase.md). Evidence: [examples/prisma-8-demo/src/queries/dml-operations.ts](examples/prisma-8-demo/src/queries/dml-operations.ts), [examples/mongo-demo/test/query-builder-writes.test.ts](examples/mongo-demo/test/query-builder-writes.test.ts). - Error routing on dotted codes in [debug.md](skills/prisma-8/references/debug.md), [migrations.md](skills/prisma-8/references/migrations.md), [migration-review.md](skills/prisma-8/references/migration-review.md). Evidence: [docs/reference/error-reference.md](docs/reference/error-reference.md), [packages/1-framework/3-tooling/cli/src/orm/migration/status-findings.ts](packages/1-framework/3-tooling/cli/src/orm/migration/status-findings.ts). - Envelope config and extension registration in [contract.md](skills/prisma-8/references/contract.md), [supabase.md](skills/prisma-8/references/supabase.md). Evidence: [examples/prisma-8-demo/prisma.config.ts](examples/prisma-8-demo/prisma.config.ts), [examples/supabase/prisma.config.ts](examples/supabase/prisma.config.ts). - Migration authoring shape in [migrations.md](skills/prisma-8/references/migrations.md). Evidence: [examples/prisma-8-demo/migrations/app/20260810T1108_add_post_engagement_counters/migration.ts](examples/prisma-8-demo/migrations/app/20260810T1108_add_post_engagement_counters/migration.ts), [packages/3-targets/3-targets/postgres/src/core/migrations/postgres-migration.ts](packages/3-targets/3-targets/postgres/src/core/migrations/postgres-migration.ts). - Init facts and commands in [quickstart.md](skills/prisma-8/references/quickstart.md). Evidence: [packages/1-framework/3-tooling/cli/src/orm/init.ts](packages/1-framework/3-tooling/cli/src/orm/init.ts), [docs/releases/v8.0.0-rc.6.md](docs/releases/v8.0.0-rc.6.md). - Middleware surface (custom `afterQuery`, cache, `family-runtime`) in [runtime.md](skills/prisma-8/references/runtime.md). Evidence: [examples/prisma-8-demo/src/prisma/db.ts](examples/prisma-8-demo/src/prisma/db.ts), [packages/3-extensions/middleware-cache/README.md](packages/3-extensions/middleware-cache/README.md). ## Testing performed - `pnpm lint:skills` (frontmatter validation; the SKILL.md description had to be trimmed under 1024 characters). - The Postgres query samples (query vs execute, array `insert`, combinators, N:M include and nested create, count reducer, cursor pagination, `db.prepare`, transaction `query`/`execute`, `first({ pk })`) and the `migration.ts` sample were typechecked against `examples/prisma-8-demo` in a scratch file that is not committed. All pass; the migration sample additionally hits a declaration-emit portability error caused only by its scratch location under `src/`. - No automated test covers skill prose; the journey tests are manual checklists. ## Follow-ups - The rendered `migration.ts` scaffold's `this.dataTransform(endContract, …)` does not typecheck against the JSON import (see reviewer notes). Worth a ticket if users typecheck their migrations. ## Alternatives considered - **Keep the flat `db.orm.User` samples and add a caveat.** Rejected: the flat form is a type error on the Postgres façade, and a caveat an agent may skip is exactly how stale lines become broken code. Every Postgres sample now uses the namespace coordinate. - **Rewrite the skill's `@internal/*` paths to `@prisma/orm-*` wholesale.** Rejected per the brief: the `@internal` spelling is a known convention; only paths the internal façade does not export use the public name. - **Drop the `migration status` diagnostics table entirely.** Rejected: the three real findings are worth routing on; the table now lists only those and points at the `--json` document for the states that were previously invented codes. ## Checklist - [x] All commits are signed off (`git commit -s`) per the [DCO](../CONTRIBUTING.md#developer-certificate-of-origin-dco). The DCO status check will block merge if any commit is missing a `Signed-off-by:` trailer. - [x] I read [CONTRIBUTING.md](../CONTRIBUTING.md) and the change is scoped to one logical concern. - [x] Tests are updated (n/a — doc-only skill content; the manual journey checklists that carried stale facts were updated). - [ ] The PR title is in `TML-NNNN: <sentence-case title>` form — no Linear ticket exists for this pass; retitle once one is filed. - [x] The **Skill update** section above is filled in. ## Notes for the reviewer See *Reviewer notes* above. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated Prisma 8 guidance for current `prisma` CLI commands, configuration formats, structured error codes, contract authoring, and migration workflows. - Clarified migration planning and status reporting, destructive-operation confirmation, database apply behavior, and CI checks. - Revised query and runtime examples for namespace-aware access, row versus write execution, prepared statements, streaming, middleware, caching, and MongoDB. - Added guidance for temporal types, scalar-list capabilities, Supabase integration, and current package import paths. - **Tests** - Updated onboarding and Vite journey tests for current contract paths and migration error output. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <[email protected]> Signed-off-by: Will Madden <[email protected]> Co-authored-by: Claude Fable 5.1 <[email protected]>
PreviousNext