Restore Prisma Next getting-started docs#7999
Merged
Merged
Conversation
- Replace "not production ready" callouts with Early Access notes across the Prisma Next docs pages, the Prisma Next blog series, and the ORM / Console feature-maturity definitions. New messaging: Prisma Next is the next major version of Prisma ORM, in Early Access, expect changes, share feedback; Prisma 7 is GA, keep using it for production. - Point the site nav "Docs" link to /docs/next and the nav + footer "ORM" links to /docs/orm/next so users land on Prisma Next. - Rename the ORM Next intro sidebar entry from "What is Prisma Next?" to "Prisma Next" for parity with the Prisma ORM (Latest) docs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Apply the approved callout wording across all Prisma Next docs pages: invite users to try the cutting-edge next major version in Early Access and share feedback, and point anyone who wants the current GA release to Prisma 7. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Early Access now means: ready to try out, cutting edge, and evolving with user feedback, with an API surface that won't change drastically. Removes the "prepared for significant breaking changes" framing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…aning Keeps the Early Access -> Preview -> GA ladder monotonic: Preview is now described as close to stable, validate in staging, rather than "not recommended in production." Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Redirect bare /docs to /docs/next so the docs land on Prisma Next by default. Keep the Prisma 7 (Latest) getting-started reachable at /docs/getting-started: repoint the getting-started version switcher's Latest target and the Getting Started tab there (bare "/" now redirects), and update the callouts' Prisma 7 links to /getting-started. - Add spacing under the callout title so the heading no longer sits flush against the body (applies to all callouts via CalloutTitle). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Incorporate Ty's feedback on the Prisma Next getting-started docs: - Remove the auto-redirect from bare /docs to /docs/next; the docs now land on Introduction to Prisma. - Remove the "Docs version" dropdown on getting-started pages. Prisma Next lives inline in the getting-started sidebar as its own sections instead of a separate rooted version. The ORM version dropdown is unchanged. - Restructure the getting-started sidebar into: Getting Started, Get started with Prisma Next, Prisma Next (Quickstart + Add to Existing Project), Prisma ORM, and Prisma Postgres. - Add a Prisma Next entry to the Prisma Postgres > Quickstart dropdown; the page moves to /prisma-postgres/quickstart/prisma-next with a redirect from the old path. - Add a non-forceful Prisma Next callout on Introduction to Prisma. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bring back the Prisma Next getting-started work from aman/prisma-next-getting-started that was overridden on main. Conflicts resolved to keep both main and branch intent: - docs/site layout: keep Compute nav plus /next paths and Early Access banner imports - footer/site ORM link points to /docs/orm/next - (index)/index.mdx keeps Compute section and adds Prisma Next note Co-authored-by: Cursor <cursoragent@cursor.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
WalkthroughThis PR adds Prisma Next docs and onboarding pages, updates Early Access wording across blog/docs content, and wires docs navigation, redirects, banners, and version-aware routing so Prisma Next routes and links resolve correctly. ChangesPrisma Next Documentation Content
Estimated code review effort: 3 (Moderate) | ~30 minutes Docs App Navigation and Banner Infrastructure
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Poem A rabbit hops through docs anew, 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
Contributor
🍈 Lychee Link Check Report123 links: ✅ All links are working!Full Statistics Table
|
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
ankur-arch
previously approved these changes
Jul 3, 2026
Fix spellcheck CI failure from the restored Prisma Next ORM overview, which uses "inspectable" and "arktype" (arktype-json extension). Co-authored-by: Cursor <cursoragent@cursor.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (8)
apps/docs/content/docs/cli/next/db-verify.mdx (1)
15-17: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
npmfences for the command examples.These snippets are fenced as
bash, so the docs tooling will not auto-render the bun/yarn/pnpm/npm tabs this repo uses elsewhere. Switching them tonpmkeeps the CLI docs consistent. Based on learnings, use a single npm fenced code block and let the tooling convert it into tabbed commands for bun, yarn, pnpm, and npm.♻️ Proposed fix
-```bash +```npm prisma-next db verify --db "$DATABASE_URL" -``` +```Apply the same fence change to the other command snippets on this page.
Also applies to: 32-43
🤖 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 `@apps/docs/content/docs/cli/next/db-verify.mdx` around lines 15 - 17, The CLI examples on this docs page are fenced as bash, which prevents the docs tooling from generating the standard package-manager tabs. Update the command snippets in the db-verify MDX content to use npm fences instead of bash, and apply the same fence change to every command example on the page so the rendered docs stay consistent with other CLI pages.Source: Learnings
apps/docs/content/docs/cli/next/index.mdx (1)
22-31: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
npmfences for the CLI snippets.These blocks are fenced as
bash, so the docs tooling will not generate the package-manager tabs this page is aiming for. Switching them tonpmkeeps the reference consistent with the rest ofapps/docs/content. Based on learnings, use a single npm fenced code block and let the tooling render bun/yarn/pnpm/npm tabs.♻️ Proposed fix
-```bash +```npm npx prisma-next help npx prisma-next contract emit -``` +```Apply the same fence change to the other command snippets on this page.
Also applies to: 39-43, 47-62
🤖 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 `@apps/docs/content/docs/cli/next/index.mdx` around lines 22 - 31, The CLI command examples on the Next docs page are fenced as plain bash blocks, so the package-manager tab tooling will not render them correctly. Update the affected command snippets to use the npm fence instead of bash, and keep each snippet as a single npm code block so the docs system can generate the bun/yarn/pnpm/npm tabs consistently. Apply the same fence change to all command examples on this page, including the install/help/contract emit snippets.Source: Learnings
apps/docs/content/docs/cli/next/init.mdx (1)
15-23: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
npmfences for the command examples.These snippets are fenced as
bash, so the docs tooling will not auto-generate the bun/yarn/pnpm/npm tabs this repo expects. Switching them tonpmkeeps the init guide aligned with the rest of the docs. Based on learnings, use a single npm fenced code block and let the tooling convert it into tabbed commands for bun, yarn, pnpm, and npm.♻️ Proposed fix
-```bash +```npm prisma-next init -``` +```Apply the same fence change to the remaining command snippets in this file.
Also applies to: 50-69
🤖 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 `@apps/docs/content/docs/cli/next/init.mdx` around lines 15 - 23, The command examples in the init guide are fenced as bash, which prevents the docs tooling from generating the expected package-manager tabs. Update the command snippets in the init documentation to use the npm fence instead of bash, and apply the same change to every command example in this file so the tooling can convert them into bun, yarn, pnpm, and npm tabs consistently.Source: Learnings
apps/docs/src/components/sidebar-badge-provider.tsx (1)
36-51: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate "is Next route" detection logic vs.
version.tshelpers.This reimplements next-route detection via raw string prefix checks.
version.tsalready exposesgetGettingStartedVersionFromPathname,getCliVersionFromPathname, andgetOrmVersionFromPathname, each of which returns"next"for exactly these routes. Reusing them would keep a single source of truth for what counts as a "Next" route, so if the Next route roots ever change, this file won't silently drift out of sync.♻️ Proposed refactor using existing version helpers
-function shouldHideSidebarBadge(url: string, badge: BadgeType | undefined) { - if (badge !== "early-access") { - return false; - } - - const docsPathname = url.replace(/^\/docs(?=\/|$)/, "") || "/"; - - return ( - docsPathname === "/next" || - docsPathname.startsWith("/next/") || - docsPathname === "/orm/next" || - docsPathname.startsWith("/orm/next/") || - docsPathname === "/cli/next" || - docsPathname.startsWith("/cli/next/") - ); -} +function shouldHideSidebarBadge(url: string, badge: BadgeType | undefined) { + if (badge !== "early-access") { + return false; + } + + const version = + getGettingStartedVersionFromPathname(url) ?? + getCliVersionFromPathname(url) ?? + getOrmVersionFromPathname(url); + + return version === "next"; +}Based on learnings from the upstream contract (
version.tscontext snippet), which defines Version path mapping defines legacy /next/* paths as corresponding to the canonical /prisma-orm/* quickstart/getting-started sections route-detection semantics that this file re-derives independently.🤖 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 `@apps/docs/src/components/sidebar-badge-provider.tsx` around lines 36 - 51, The Next-route check in shouldHideSidebarBadge is duplicating path logic that already exists in version.ts. Replace the raw "/next", "/orm/next", and "/cli/next" prefix checks with the existing getGettingStartedVersionFromPathname, getOrmVersionFromPathname, and getCliVersionFromPathname helpers, and hide the early-access badge when any of them returns "next". Keep the badge-type guard, but make version.ts the single source of truth for route detection.apps/docs/src/components/version-switcher.tsx (1)
35-57: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUnreachable
isGettingStartedVersionbranches after early return.Since Line 40-42 already returns
nullwhenisGettingStartedVersionis true,isGettingStartedVersionis guaranteedfalsefor the rest of the function. That makes thegetGettingStartedVersionFromPathname(pathname)call in the??chain (Line 45) always resolve tonull, and theisGettingStartedVersionchecks inusesScopedVersions(Line 49) andlabel(Line 53) dead code that always take their "false" branch. This is harmless today but misleading — a future edit near the early return (e.g. relaxing it) would silently change behavior here without anyone noticing these branches were already assumed unreachable.♻️ Suggested simplification
- const detectedVersion = - getGettingStartedVersionFromPathname(pathname) ?? - getCliVersionFromPathname(pathname) ?? - getOrmVersionFromPathname(pathname); - const currentVersion = detectedVersion ?? null; - const usesScopedVersions = isGettingStartedVersion || isCliVersion; - const visibleVersions = usesScopedVersions + const currentVersion = + getCliVersionFromPathname(pathname) ?? getOrmVersionFromPathname(pathname) ?? null; + const visibleVersions = isCliVersion ? versions.filter((version) => version === LATEST_VERSION || version === "next") : versions; - const label = isGettingStartedVersion - ? "Docs version" - : isCliVersion - ? "CLI version" - : "ORM version"; + const label = isCliVersion ? "CLI version" : "ORM version";🤖 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 `@apps/docs/src/components/version-switcher.tsx` around lines 35 - 57, Remove the dead `isGettingStartedVersion` branches in `VersionSwitcher`: since the early `return null` already excludes getting-started pages, `getGettingStartedVersionFromPathname(pathname)` in the `detectedVersion` chain, plus the `isGettingStartedVersion` checks in `usesScopedVersions` and `label`, are unreachable. Simplify those expressions to only use the CLI/ORM path helpers and base the scoped-version filtering and label selection on the remaining `isCliVersion`/default logic.apps/docs/src/lib/versioned-sidebar-tree.ts (1)
116-277: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winGetting Started and CLI sidebar filtering are near-duplicate implementations.
filterGettingStartedSidebarTree/filterCliSidebarTree,findGettingStartedNode/findCliNode, andgetGettingStartedSidebarTree/getCliSidebarTreeeach repeat the same shape of logic, differing only in the node predicate and "next"-node predicate used. Consolidating into a single generic implementation parameterized byisSectionNode/isVersionNodepredicates would cut ~100 lines of duplication and reduce the risk of the two sections drifting apart when one is updated but not the other (as already hinted by the GS/CLI naming asymmetry above).🤖 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 `@apps/docs/src/lib/versioned-sidebar-tree.ts` around lines 116 - 277, The Getting Started and CLI sidebar helpers are duplicated and should be unified into one generic implementation. Refactor filterGettingStartedSidebarTree/filterCliSidebarTree, findGettingStartedNode/findCliNode, and getGettingStartedSidebarTree/getCliSidebarTree into shared helpers parameterized by the section predicate and version-node predicate (for example, isGettingStartedNode/isCliNode and isGettingStartedVersionNode/isCliVersionNode). Keep the current behavior for selecting the "next" version and for preserving index/children, but route both sections through the same logic to avoid drift.apps/docs/src/lib/version.ts (2)
229-254: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate root-switch/candidate logic between CLI and ORM branches.
getCliSwitchPathnameand the ORM fallback path insidegetVersionSwitchPathnameboth independently: compute a suffix from the current root, build a${targetRoot}${suffix}candidate, check it againstgetAvailablePathnameSet, and fall back totargetRoot. Extracting this into one shared helper (parameterized by current/target root) would remove the duplication and keep both paths behaviorally in sync going forward.♻️ Suggested consolidation
+function switchRootPathname( + docsPathname: string, + currentRoot: string, + targetRoot: string, + availablePathnames: Iterable<string>, +) { + const suffix = + docsPathname === currentRoot + ? "" + : docsPathname.startsWith(`${currentRoot}/`) + ? docsPathname.slice(currentRoot.length) + : ""; + const candidate = `${targetRoot}${suffix}`; + const available = getAvailablePathnameSet(availablePathnames); + + return available.size === 0 || available.has(candidate) ? candidate : targetRoot; +}Then both
getCliSwitchPathnameand the ORM branch ofgetVersionSwitchPathnamecan callswitchRootPathname(...)instead of repeating the suffix/candidate/fallback logic.Also applies to: 327-349
🤖 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 `@apps/docs/src/lib/version.ts` around lines 229 - 254, The CLI switch path logic duplicates the same root/suffix/candidate/fallback flow used in the ORM branch of getVersionSwitchPathname. Extract that shared behavior into a helper like switchRootPathname that takes the current root, target root, docsPathname, and availablePathnames, then have getCliSwitchPathname and the ORM fallback call it directly. Keep the existing candidate-building and getAvailablePathnameSet check semantics unchanged so both branches stay aligned.
23-61: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove the unreachable Getting Started switch path maps
VersionSwitcherreturnsnullforisGettingStartedVersionPathname(pathname), andgetVersionSwitchPathnameis only called from that component. If nothing else switches versions from a Getting Started pathname,getGettingStartedSwitchPathnameand its two maps can be removed.🤖 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 `@apps/docs/src/lib/version.ts` around lines 23 - 61, The Getting Started switch path logic is unreachable, since VersionSwitcher returns null for isGettingStartedVersionPathname(pathname) and getVersionSwitchPathname only routes through that component. Remove getGettingStartedSwitchPathname and the two Maps NEXT_GETTING_STARTED_PATHS_BY_LATEST_PATH and LATEST_GETTING_STARTED_PATHS_BY_NEXT_PATH from version.ts, and clean up any related dead references while keeping the other version-switch path helpers intact.
🤖 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 `@apps/docs/content/docs/`(index)/next/quickstart/mongodb.mdx:
- Around line 85-88: The Next.js MongoDB quickstart “Next steps” list points to
the wrong Prisma schema location; update the guidance in the quickstart content
to reference prisma/contract.prisma instead of src/prisma/contract.prisma. Make
sure the wording stays consistent with the existing docs and only changes the
incorrect file path in the relevant quickstart section.
In `@apps/docs/content/docs/`(index)/prisma-postgres/quickstart/prisma-next.mdx:
- Around line 54-56: The quickstart prerequisite text is mismatched with the
linked add-to-existing-project guide, so update the bullet in the Prisma
Postgres quickstart content to match what the
`/next/add-to-existing-project/postgresql` page actually covers. In the Markdown
around the existing “Use the PostgreSQL existing-project guide” item, either
change the wording to describe an existing PostgreSQL app or switch the link to
the correct Prisma Postgres guide, using the same list item text and nearby
“Import from PostgreSQL/MySQL” bullets as the reference point.
In `@apps/docs/content/docs/cli/next/db-init.mdx`:
- Around line 15-17: The CLI examples in the docs MDX use bash fences, which
prevents the package-manager tab conversion from working. Update the command
examples in db-init.mdx to use npm fences consistently, and keep each command
example in the expected single fenced block style so the docs tooling can render
bun/yarn/pnpm/npm tabs correctly. Refer to the existing prisma-next db init,
prisma-next contract emit, and prisma-next db verify examples when making the
replacement.
In `@apps/docs/content/docs/cli/next/db-schema.mdx`:
- Around line 15-17: The command examples in this MDX doc are fenced as bash,
which prevents the docs tooling from generating the package-manager tabs
expected in this section. Update the code examples to use a single npm fenced
block in the relevant docs snippet(s) so the tooling can convert them into bun,
yarn, pnpm, and npm tabs; use the existing command examples around the db schema
usage as the target for this change.
In `@apps/docs/content/docs/cli/next/db-sign.mdx`:
- Around line 15-17: The command examples in the docs MDX are using bash fences,
which prevents the package-manager tab conversion; update the fenced code blocks
in the db sign section to use a single npm code block so the docs tooling can
generate the bun, yarn, pnpm, and npm tabs. Apply this in the command example
blocks around the db sign/verify commands, keeping the content the same but
changing the fence language to npm.
In `@apps/docs/content/docs/cli/next/db-update.mdx`:
- Around line 15-17: The CLI examples in this MDX file are using bash fences,
which prevents the docs tooling from generating package-manager tabs. Update the
command examples in the db update section to use a single npm fenced code block
instead of bash, matching the existing docs convention used by the CLI content
and ensuring the tab conversion works for all commands like prisma-next db
update and prisma-next contract emit.
In `@apps/docs/content/docs/orm/index.mdx`:
- Around line 17-20: The Prisma Next CTA in the `index.mdx` docs callout points
to the overview page instead of the getting-started flow. Update the link target
in the “Try Prisma Next” tip so the “Prisma Next getting started guide” anchor
points to the getting-started page, keeping the existing callout text and using
the same `:::tip[Try Prisma Next]` block.
In `@apps/docs/cspell.json`:
- Around line 57-58: The dictionary entries use the wrong brand casing, so
spellcheck will still miss the real term. Update the cspell dictionary entries
for the CipherStash brand to use the exact casing consistently, and make sure
the existing dictionary list includes the corrected spelling alongside any
needed variants in the cspell configuration.
In `@apps/docs/next.config.mjs`:
- Around line 285-289: The Next/Postgres switch target is inconsistent between
the redirect and the version mapping. Update the mapping in version.ts for the
/next/prisma-postgres/quickstart/prisma-next source so it points to the same
canonical destination as the redirect in next.config.mjs, and keep the relevant
entries in sync to avoid the version picker and hard redirect landing on
different pages.
---
Nitpick comments:
In `@apps/docs/content/docs/cli/next/db-verify.mdx`:
- Around line 15-17: The CLI examples on this docs page are fenced as bash,
which prevents the docs tooling from generating the standard package-manager
tabs. Update the command snippets in the db-verify MDX content to use npm fences
instead of bash, and apply the same fence change to every command example on the
page so the rendered docs stay consistent with other CLI pages.
In `@apps/docs/content/docs/cli/next/index.mdx`:
- Around line 22-31: The CLI command examples on the Next docs page are fenced
as plain bash blocks, so the package-manager tab tooling will not render them
correctly. Update the affected command snippets to use the npm fence instead of
bash, and keep each snippet as a single npm code block so the docs system can
generate the bun/yarn/pnpm/npm tabs consistently. Apply the same fence change to
all command examples on this page, including the install/help/contract emit
snippets.
In `@apps/docs/content/docs/cli/next/init.mdx`:
- Around line 15-23: The command examples in the init guide are fenced as bash,
which prevents the docs tooling from generating the expected package-manager
tabs. Update the command snippets in the init documentation to use the npm fence
instead of bash, and apply the same change to every command example in this file
so the tooling can convert them into bun, yarn, pnpm, and npm tabs consistently.
In `@apps/docs/src/components/sidebar-badge-provider.tsx`:
- Around line 36-51: The Next-route check in shouldHideSidebarBadge is
duplicating path logic that already exists in version.ts. Replace the raw
"/next", "/orm/next", and "/cli/next" prefix checks with the existing
getGettingStartedVersionFromPathname, getOrmVersionFromPathname, and
getCliVersionFromPathname helpers, and hide the early-access badge when any of
them returns "next". Keep the badge-type guard, but make version.ts the single
source of truth for route detection.
In `@apps/docs/src/components/version-switcher.tsx`:
- Around line 35-57: Remove the dead `isGettingStartedVersion` branches in
`VersionSwitcher`: since the early `return null` already excludes
getting-started pages, `getGettingStartedVersionFromPathname(pathname)` in the
`detectedVersion` chain, plus the `isGettingStartedVersion` checks in
`usesScopedVersions` and `label`, are unreachable. Simplify those expressions to
only use the CLI/ORM path helpers and base the scoped-version filtering and
label selection on the remaining `isCliVersion`/default logic.
In `@apps/docs/src/lib/version.ts`:
- Around line 229-254: The CLI switch path logic duplicates the same
root/suffix/candidate/fallback flow used in the ORM branch of
getVersionSwitchPathname. Extract that shared behavior into a helper like
switchRootPathname that takes the current root, target root, docsPathname, and
availablePathnames, then have getCliSwitchPathname and the ORM fallback call it
directly. Keep the existing candidate-building and getAvailablePathnameSet check
semantics unchanged so both branches stay aligned.
- Around line 23-61: The Getting Started switch path logic is unreachable, since
VersionSwitcher returns null for isGettingStartedVersionPathname(pathname) and
getVersionSwitchPathname only routes through that component. Remove
getGettingStartedSwitchPathname and the two Maps
NEXT_GETTING_STARTED_PATHS_BY_LATEST_PATH and
LATEST_GETTING_STARTED_PATHS_BY_NEXT_PATH from version.ts, and clean up any
related dead references while keeping the other version-switch path helpers
intact.
In `@apps/docs/src/lib/versioned-sidebar-tree.ts`:
- Around line 116-277: The Getting Started and CLI sidebar helpers are
duplicated and should be unified into one generic implementation. Refactor
filterGettingStartedSidebarTree/filterCliSidebarTree,
findGettingStartedNode/findCliNode, and
getGettingStartedSidebarTree/getCliSidebarTree into shared helpers parameterized
by the section predicate and version-node predicate (for example,
isGettingStartedNode/isCliNode and
isGettingStartedVersionNode/isCliVersionNode). Keep the current behavior for
selecting the "next" version and for preserving index/children, but route both
sections through the same logic to avoid drift.
🪄 Autofix (Beta)
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.yaml
Review profile: CHILL
Plan: Pro
Run ID: d8bf4eac-fbd8-45e0-a61f-1f9fcd837b25
📒 Files selected for processing (58)
apps/blog/content/blog/data-migrations-in-prisma-next/index.mdxapps/blog/content/blog/mongodb-without-compromise/index.mdxapps/blog/content/blog/prisma-next-call-for-extension-authors/index.mdxapps/blog/content/blog/the-next-evolution-of-prisma-orm/index.mdxapps/docs/content/docs/(index)/index.mdxapps/docs/content/docs/(index)/meta.jsonapps/docs/content/docs/(index)/next/add-to-existing-project/meta.jsonapps/docs/content/docs/(index)/next/add-to-existing-project/mongodb.mdxapps/docs/content/docs/(index)/next/add-to-existing-project/postgresql.mdxapps/docs/content/docs/(index)/next/getting-started.mdxapps/docs/content/docs/(index)/next/index.mdxapps/docs/content/docs/(index)/next/prisma-postgres/from-the-cli.mdxapps/docs/content/docs/(index)/next/prisma-postgres/import-from-existing-database-mysql.mdxapps/docs/content/docs/(index)/next/prisma-postgres/import-from-existing-database-postgresql.mdxapps/docs/content/docs/(index)/next/prisma-postgres/meta.jsonapps/docs/content/docs/(index)/next/quickstart/meta.jsonapps/docs/content/docs/(index)/next/quickstart/mongodb.mdxapps/docs/content/docs/(index)/next/quickstart/postgresql.mdxapps/docs/content/docs/(index)/prisma-postgres/quickstart/meta.jsonapps/docs/content/docs/(index)/prisma-postgres/quickstart/prisma-next.mdxapps/docs/content/docs/cli/meta.jsonapps/docs/content/docs/cli/next/configuration.mdxapps/docs/content/docs/cli/next/contract-emit.mdxapps/docs/content/docs/cli/next/contract-infer.mdxapps/docs/content/docs/cli/next/db-init.mdxapps/docs/content/docs/cli/next/db-schema.mdxapps/docs/content/docs/cli/next/db-sign.mdxapps/docs/content/docs/cli/next/db-update.mdxapps/docs/content/docs/cli/next/db-verify.mdxapps/docs/content/docs/cli/next/index.mdxapps/docs/content/docs/cli/next/init.mdxapps/docs/content/docs/cli/next/meta.jsonapps/docs/content/docs/cli/next/migration-apply.mdxapps/docs/content/docs/cli/next/migration-new.mdxapps/docs/content/docs/cli/next/migration-plan.mdxapps/docs/content/docs/cli/next/migration-ref.mdxapps/docs/content/docs/cli/next/migration-show.mdxapps/docs/content/docs/cli/next/migration-status.mdxapps/docs/content/docs/console/more/feature-maturity.mdxapps/docs/content/docs/orm/index.mdxapps/docs/content/docs/orm/more/releases.mdxapps/docs/content/docs/orm/next/index.mdxapps/docs/content/docs/orm/next/meta.jsonapps/docs/cspell.jsonapps/docs/next.config.mjsapps/docs/src/app/(docs)/(default)/layout.tsxapps/docs/src/app/global.cssapps/docs/src/app/layout.tsxapps/docs/src/components/layout/link-item.tsxapps/docs/src/components/layout/notebook/page/client.tsxapps/docs/src/components/sidebar-badge-provider.tsxapps/docs/src/components/version-switcher.tsxapps/docs/src/lib/layout.shared.tsxapps/docs/src/lib/version.tsapps/docs/src/lib/versioned-sidebar-tree.tsapps/docs/src/mdx-components.tsxapps/site/src/app/layout.tsxpackages/ui/src/data/footer.ts
ankur-arch
approved these changes
Jul 3, 2026
This was referenced Jul 3, 2026
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
3 participants
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.
Summary
The Prisma Next getting-started work from
aman/prisma-next-getting-startedwas overridden onmain. This PR brings it back by merging that branch onto the latestmainand resolving conflicts.Restored/added:
apps/docs/content/docs/(index)/next/**— Prisma Next getting-started, quickstart, add-to-existing-project, and Prisma Postgres pagesapps/docs/content/docs/cli/next/**— Prisma Next CLI referenceapps/docs/content/docs/orm/next/**— Prisma Next ORM sectionsrc/lib/version.ts,versioned-sidebar-tree.ts,version-switcher.tsx, and the Early Access banner in the docs layoutConflict resolutions
Kept both
mainand branch intent where they overlapped:apps/docs/src/app/layout.tsx): keepGoogleTagManagerplus the branch'sBanner/ArrowRightIconEarly Access banner importsactivePathscombines/prisma-compute(main) and/next(branch)/docs/orm/next(branch)prisma-next/)Test plan
/nextpages render/nextMade with Cursor
Summary by CodeRabbit