@prisma/orm-mongo 8.0.0-rc.11-dev.5 → 8.0.0-rc.11-dev.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@prisma/orm-mongo",
|
|
3
|
-
"version": "8.0.0-rc.11-dev.
|
|
3
|
+
"version": "8.0.0-rc.11-dev.6",
|
|
4
4
|
"license": "Apache-2.0",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"sideEffects": false,
|
|
@@ -10,16 +10,16 @@
|
|
|
10
10
|
"skills"
|
|
11
11
|
],
|
|
12
12
|
"dependencies": {
|
|
13
|
-
"@prisma/orm-family-mongo": "8.0.0-rc.11-dev.
|
|
14
|
-
"@prisma/orm-framework": "8.0.0-rc.11-dev.
|
|
15
|
-
"@prisma/orm-target-mongo": "8.0.0-rc.11-dev.
|
|
16
|
-
"@prisma/orm-toolchain": "8.0.0-rc.11-dev.
|
|
13
|
+
"@prisma/orm-family-mongo": "8.0.0-rc.11-dev.6",
|
|
14
|
+
"@prisma/orm-framework": "8.0.0-rc.11-dev.6",
|
|
15
|
+
"@prisma/orm-target-mongo": "8.0.0-rc.11-dev.6",
|
|
16
|
+
"@prisma/orm-toolchain": "8.0.0-rc.11-dev.6",
|
|
17
17
|
"pathe": "^2.0.3"
|
|
18
18
|
},
|
|
19
19
|
"devDependencies": {
|
|
20
|
-
"@internal/mongo": "8.0.0-rc.11-dev.
|
|
21
|
-
"@repo/tsconfig": "8.0.0-rc.11-dev.
|
|
22
|
-
"@repo/tsdown": "8.0.0-rc.11-dev.
|
|
20
|
+
"@internal/mongo": "8.0.0-rc.11-dev.6",
|
|
21
|
+
"@repo/tsconfig": "8.0.0-rc.11-dev.6",
|
|
22
|
+
"@repo/tsdown": "8.0.0-rc.11-dev.6",
|
|
23
23
|
"tsdown": "0.22.14",
|
|
24
24
|
"typescript": "5.9.3"
|
|
25
25
|
},
|
package/skills/prisma-8/SKILL.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Upgrade Prisma 8 (user app)
|
|
2
2
|
|
|
3
|
-
This reference upgrades a project that **consumes** Prisma 8 via the public package API (`@
|
|
3
|
+
This reference upgrades a project that **consumes** Prisma 8 via the public package API (`@prisma/orm-postgres`, `@prisma/orm-mongo`, `@prisma/orm-sqlite`, the contract files in `prisma/`, etc.). Package names below are the published `@prisma/orm-*` names, which is what `package.json`, the lockfile, and the registry use; the other references in this skill spell import paths as `@internal/<target>`, and SKILL.md explains that mapping. If the project is itself a Prisma 8 *extension*, use [`upgrade-extension.md`](upgrade-extension.md) instead — or both, if the repo contains both an app and an extension package.
|
|
4
4
|
|
|
5
5
|
The per-transition instructions this reference reads live under [`../upgrading/app/upgrades/`](../upgrading/app/upgrades/).
|
|
6
6
|
|
|
@@ -12,12 +12,12 @@ Do the version bump first (step 1 of the per-step flow below), re-sync the skill
|
|
|
12
12
|
|
|
13
13
|
## Pre-flight — extension compatibility
|
|
14
14
|
|
|
15
|
-
Before changing any code, refuse to upgrade past any installed extension's pinned Prisma 8 version. Extensions in Prisma 8 pin every `@
|
|
15
|
+
Before changing any code, refuse to upgrade past any installed extension's pinned Prisma 8 version. Extensions in Prisma 8 pin every `@prisma/orm-*` dependency to a single exact version (no carets, no ranges); that pin is the highest version the extension has been validated against. Upgrading the user app past that pin would silently desynchronise the extension's type identity from the app's.
|
|
16
16
|
|
|
17
17
|
Steps:
|
|
18
18
|
|
|
19
19
|
1. **Read `prisma.config.ts`** (or its TS-discoverable equivalent at the project root) and enumerate the list of extension packages it imports. Each `extensions: [...]` entry corresponds to an installed npm package.
|
|
20
|
-
2. **For each extension**, read its installed `package.json` from `node_modules/<extension-package-name>/package.json` and find
|
|
20
|
+
2. **For each extension**, read its installed `package.json` from `node_modules/<extension-package-name>/package.json` and find every `@prisma/orm-*` entry under `dependencies`, `peerDependencies`, or `optionalDependencies` (`@prisma/orm-framework`, `@prisma/orm-family-sql` or `@prisma/orm-family-mongo`, `@prisma/orm-toolchain`, and a `@prisma/orm-target-*` peer). By construction those entries are exact-version pins (e.g. `"8.0.0-rc.11"`), set when the extension author last ran their own upgrade.
|
|
21
21
|
3. **Compute the lowest pinned version across all extensions.** That is the highest Prisma 8 version reachable by this app on its current extension set.
|
|
22
22
|
4. **Compare to the user's target.** If the target exceeds the lowest pin, halt with a structured message naming each lagging extension and its pinned version, and offer two paths:
|
|
23
23
|
- (a) Wait for the lagging extension to publish a compatible release, then re-run.
|
|
@@ -31,15 +31,15 @@ If `prisma.config.ts` is absent or names no extensions, skip the pre-flight.
|
|
|
31
31
|
|
|
32
32
|
This flow applies when the project **consumes** Prisma 8:
|
|
33
33
|
|
|
34
|
-
- `package.json` declares
|
|
35
|
-
- the package is *not* itself an extension (no `@
|
|
34
|
+
- `package.json` declares `@prisma/orm-postgres`, `@prisma/orm-mongo`, or `@prisma/orm-sqlite` under `dependencies` / `devDependencies`, and
|
|
35
|
+
- the package is *not* itself an extension (no `@prisma/orm-framework` or other SPI package under `dependencies`/`peerDependencies`; name does not match `^@.*/extension-`; not referenced from a sibling app's `prisma.config.ts`).
|
|
36
36
|
|
|
37
37
|
If the project also matches the extension-author role, run **this** flow first and then [`upgrade-extension.md`](upgrade-extension.md) in the same session. If detection is ambiguous, ask the user.
|
|
38
38
|
|
|
39
39
|
## Version detection
|
|
40
40
|
|
|
41
|
-
- **From-version.** Read the currently-installed Prisma 8 version from `pnpm-lock.yaml` (or `package-lock.json` / `yarn.lock`) by inspecting the resolved version of
|
|
42
|
-
- **To-version.** Either the version the user specified, or whatever `npm view @
|
|
41
|
+
- **From-version.** Read the currently-installed Prisma 8 version from `pnpm-lock.yaml` (or `package-lock.json` / `yarn.lock`) by inspecting the resolved version of the app's Prisma packages: `@prisma/orm-postgres`, `@prisma/orm-mongo`, or `@prisma/orm-sqlite`. Do not read it from a `@prisma/orm-extension-*` package; extensions carry their own version and are handled by the pre-flight above. Compare full semver strings, prerelease identifier included: `8.0.0-rc.10` and `8.0.0-rc.11` are different versions and different steps in the chain below. If the lockfile shows the app's Prisma packages at different versions (already broken), the **lowest** is the from-version.
|
|
42
|
+
- **To-version.** Either the version the user specified, or whatever `npm view @prisma/orm-postgres dist-tags.latest` reports. Do not assume that is a stable version: while Prisma 8 is a release candidate, `latest` tracks the newest release, `8.0.0-rc.N` included. If the user wants a stable version specifically, they must name it.
|
|
43
43
|
|
|
44
44
|
Report both back to the user before continuing.
|
|
45
45
|
|
|
@@ -61,7 +61,7 @@ The chain order does not depend on which extensions are installed; the pre-fligh
|
|
|
61
61
|
|
|
62
62
|
For each `(from, to)` step in the chain:
|
|
63
63
|
|
|
64
|
-
1. **Bump
|
|
64
|
+
1. **Bump the app's Prisma packages.** Rewrite every `@prisma/orm-postgres`, `@prisma/orm-mongo`, and `@prisma/orm-sqlite` entry in the project's `package.json` to the exact `<to>` version (no caret, no tilde). All entries advance to the same version. Cover `dependencies` and `devDependencies`. Leave `@prisma/orm-extension-*` entries unchanged: each extension pins its own Prisma version, and the pre-flight has already confirmed every installed extension supports `<to>`. The skill itself ships inside the Prisma packages, so bumping them is what updates it; there is no separate skill package to bump.
|
|
65
65
|
|
|
66
66
|
2. **Install.** Run `pnpm install` (or the project's lockfile-managing command). The project's code is now broken against the new types — the upgrade instructions for `<from> → <to>` exist to fix it.
|
|
67
67
|
|
|
@@ -83,7 +83,7 @@ For each `(from, to)` step in the chain:
|
|
|
83
83
|
6. **Commit.** One commit per step containing the `package.json` bump, lockfile churn, and any source rewrites:
|
|
84
84
|
|
|
85
85
|
```text
|
|
86
|
-
chore: upgrade @
|
|
86
|
+
chore: upgrade @prisma/orm-* to <to-version>
|
|
87
87
|
```
|
|
88
88
|
|
|
89
89
|
(Or the project's own commit-message convention.) Never squash steps. The user may squash on merge; the in-flight history must be per-step so a failed step is bisectable.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
# Upgrade Prisma 8 (extension)
|
|
2
2
|
|
|
3
|
-
This reference upgrades a project that **is** a Prisma 8 extension — a package that consumes the framework SPI (`@
|
|
3
|
+
This reference upgrades a project that **is** a Prisma 8 extension — a package that consumes the framework SPI (`@prisma/orm-framework`, `@prisma/orm-family-sql` or `@prisma/orm-family-mongo`, `@prisma/orm-toolchain`, with a `@prisma/orm-target-*` peer) and exposes contract / middleware / codec / migration surfaces that downstream apps install via `prisma.config.ts`.
|
|
4
4
|
|
|
5
|
-
If the project you are upgrading is a consumer **app** (it
|
|
5
|
+
If the project you are upgrading is a consumer **app** (it depends on `@prisma/orm-postgres`, `@prisma/orm-mongo`, or `@prisma/orm-sqlite` from its application code), use [`upgrade-app.md`](upgrade-app.md) instead — or both, if the repo contains both a consumer app and an extension package, in which case run the app flow first then this one in the same session.
|
|
6
6
|
|
|
7
7
|
The per-transition instructions this reference reads live under [`../upgrading/extension/upgrades/`](../upgrading/extension/upgrades/).
|
|
8
8
|
|
|
@@ -16,8 +16,8 @@ Do the version bump first (step 1 of the per-step flow below), re-sync the skill
|
|
|
16
16
|
|
|
17
17
|
This flow applies when the project **is** a Prisma 8 extension. Heuristics:
|
|
18
18
|
|
|
19
|
-
- `package.json` declares `@
|
|
20
|
-
- the package's `name` matches `^@.*/extension-` (the
|
|
19
|
+
- `package.json` declares `@prisma/orm-framework` (or another `@prisma/orm-*` SPI package) under `dependencies` or `peerDependencies`, and
|
|
20
|
+
- the package's `name` matches `^@.*/extension-` (the convention used by `@prisma/orm-extension-pgvector`, etc.), or
|
|
21
21
|
- the package is referenced as an `extensions` entry from a sibling app's `prisma.config.ts` in the same monorepo.
|
|
22
22
|
|
|
23
23
|
If the project additionally consumes Prisma 8 from its own app code, run [`upgrade-app.md`](upgrade-app.md) first, then this flow in the same session.
|
|
@@ -26,8 +26,8 @@ If detection is ambiguous, ask the user which role to operate under.
|
|
|
26
26
|
|
|
27
27
|
## Version detection
|
|
28
28
|
|
|
29
|
-
- **From-version.** Read the currently-installed Prisma 8 version from `pnpm-lock.yaml` (or `package-lock.json` / `yarn.lock`) by inspecting the resolved version of any `@
|
|
30
|
-
- **To-version.** Either the version the user specified, or whatever `npm view @
|
|
29
|
+
- **From-version.** Read the currently-installed Prisma 8 version from `pnpm-lock.yaml` (or `package-lock.json` / `yarn.lock`) by inspecting the resolved version of any `@prisma/orm-*` SPI package (`@prisma/orm-framework`, `@prisma/orm-family-*`, `@prisma/orm-target-*`, `@prisma/orm-toolchain`). Do not read it from a `@prisma/orm-extension-*` dependency; another extension carries its own version. Compare full semver strings, prerelease identifier included: `8.0.0-rc.10` and `8.0.0-rc.11` are different versions and different steps in the chain below. If the lockfile shows the SPI packages at different versions, the lowest is the from-version.
|
|
30
|
+
- **To-version.** Either the version the user specified, or whatever `npm view @prisma/orm-framework dist-tags.latest` reports. Do not assume that is a stable version: while Prisma 8 is a release candidate, `latest` tracks the newest release, `8.0.0-rc.N` included. If the user wants a stable version specifically, they must name it.
|
|
31
31
|
|
|
32
32
|
Report both back to the user before continuing.
|
|
33
33
|
|
|
@@ -45,15 +45,21 @@ Apply each step in order, fully: bump, install, run instructions, check pins, va
|
|
|
45
45
|
|
|
46
46
|
## Per-step flow
|
|
47
47
|
|
|
48
|
-
This flow assumes you are an **external extension author** — your extension lives in its own repo and consumes `@
|
|
48
|
+
This flow assumes you are an **external extension author** — your extension lives in its own repo and consumes `@prisma/orm-*` from npm. (Extensions inside the `prisma/prisma` monorepo itself are bumped via `pnpm bump-version` / `scripts/set-version.ts`, which rewrites every `workspace:<X.Y.Z>` spec in lockstep with the root version; they do not run this skill.)
|
|
49
49
|
|
|
50
50
|
For each `(from, to)` step in the chain:
|
|
51
51
|
|
|
52
|
-
1. **Bump `@
|
|
52
|
+
1. **Bump `@prisma/orm-*` deps.** Rewrite every `@prisma/orm-*` entry other than `@prisma/orm-extension-*` in the extension's `package.json` to the exact `<to>` version (e.g. `"8.0.0-rc.11"` — no caret, no tilde, no range, no `workspace:` specifier; the exact-pin rule below details why). All entries advance to the same version. Cover whichever dep field(s) the extension uses today — `dependencies` and/or `peerDependencies` — and any `optionalDependencies`. The skill itself ships inside the Prisma packages, so bumping them is what updates it; there is no separate skill package to bump.
|
|
53
53
|
|
|
54
54
|
2. **Install.** Run `pnpm install` (or the project's lockfile-managing command). The extension's source is now broken against the new SPI — the upgrade instructions for `<from> → <to>` exist to fix it.
|
|
55
55
|
|
|
56
|
-
3. **Check pins.**
|
|
56
|
+
3. **Check pins.** Every `@prisma/orm-*` entry other than `@prisma/orm-extension-*` across `dependencies`, `peerDependencies`, and `optionalDependencies` must now be the single exact string `<to>`. This prints any entry that is not, and exits 1:
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
node -e 'const p=require("./package.json");const to=process.argv[1];const bad=[];for(const f of ["dependencies","peerDependencies","optionalDependencies"])for(const [n,v] of Object.entries(p[f]??{}))if(n.startsWith("@prisma/orm-")&&!n.startsWith("@prisma/orm-extension-")&&v!==to)bad.push(f+": "+n+"@"+v);if(bad.length){console.error(bad.join("\n"));process.exit(1)}' <to>
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
If it fails, the bump step did not rewrite every spec — fix the offending entries and re-run before proceeding.
|
|
57
63
|
|
|
58
64
|
4. **Read the upgrade instructions.** Re-sync the skills (`prisma skills sync`) so the tree matches the version just installed, then load `../upgrading/extension/upgrades/<from>-to-<to>/instructions.md`. Parse the YAML frontmatter and pay particular attention to its `changes[]` array.
|
|
59
65
|
|
|
@@ -73,7 +79,7 @@ For each `(from, to)` step in the chain:
|
|
|
73
79
|
7. **Commit.** Create one commit containing this step's changes: the `package.json` bump, the lockfile churn from `pnpm install`, and any source-file rewrites from the applied changes. Use the message:
|
|
74
80
|
|
|
75
81
|
```text
|
|
76
|
-
chore: upgrade @
|
|
82
|
+
chore: upgrade @prisma/orm-* to <to-version>
|
|
77
83
|
```
|
|
78
84
|
|
|
79
85
|
(Or the extension's own commit-message convention, if it has one.) One commit per step — never squash steps.
|
|
@@ -82,15 +88,9 @@ Move on to the next step. Repeat.
|
|
|
82
88
|
|
|
83
89
|
## Exact-pin rule
|
|
84
90
|
|
|
85
|
-
Prisma 8 extensions pin every `@
|
|
86
|
-
|
|
87
|
-
`prisma-8-check-pins` (shipped by `@internal/extension-author-tools` — install with `pnpm add -D @internal/extension-author-tools`) enforces the rule. Run it locally with:
|
|
88
|
-
|
|
89
|
-
```bash
|
|
90
|
-
pnpm exec prisma-8-check-pins
|
|
91
|
-
```
|
|
91
|
+
Prisma 8 extensions pin every `@prisma/orm-*` SPI dependency (everything except `@prisma/orm-extension-*`) to a single **exact** version (no `^`, no `~`, no range, no wildcard, no `workspace:` specifier in the published `package.json`). All of those entries share the same version. The pin advances after each successful upgrade step, release-candidate steps included.
|
|
92
92
|
|
|
93
|
-
Wire
|
|
93
|
+
The one-line check in step 3 of the per-step flow enforces the rule; the `prisma-8-check-pins` guard the monorepo uses for its own extensions is not published. Wire the check into the extension's CI alongside the build/test step so an accidental range pin fails the PR before it lands.
|
|
94
94
|
|
|
95
95
|
## When the chain is done
|
|
96
96
|
|