@prisma/orm-mongo 8.0.0-rc.5 → 8.0.0-rc.5-dev.2

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.3-to-8.0.0-rc.4/instructions.md

@@ -0,0 +1,158 @@
+---
+from: "8.0.0-rc.3"
+to: "8.0.0-rc.4"
+changes:
+  - id: prisma-config-hard-cut-and-top-level-commands
+    summary: |
+      The deprecated fallbacks are gone: the CLI no longer reads
+      `prisma-next.config.ts`, no longer accepts the flat (un-nested) config shape, and the
+      `prisma-next` command no longer exists. The unified CLI (`@prisma/cli`, installed from
+      the `next` dist-tag; its binary is currently `prisma-cli`) runs the ORM commands at the
+      top level — `contract emit`, `db init`, `migration plan`, `migrate` — with only `init`
+      under the `orm` group (`orm init`), and the only config it reads is `prisma.config.ts`
+      in the engine envelope shape.
+
+      1. Rename `prisma-next.config.ts` to `prisma.config.ts` if you have not already.
+      2. Rewrite the export to the envelope shape. Old flat shape:
+         `import { defineConfig } from '@prisma/orm-postgres/config';`
+         `export default defineConfig({ contract: '…', db: { connection: … } });`
+         New shape:
+         `import { definePrismaConfig } from '@prisma/cli-engine';`
+         `import { defineConfig as ormConfig } from '@prisma/orm-postgres/config';`
+         `export default definePrismaConfig({ orm: ormConfig({ contract: '…', db: { connection: … } }) });`
+         The options object moves into the target helper unchanged. The same pattern applies
+         to `@prisma/orm-sqlite/config` and `@prisma/orm-mongo/config`.
+      3. If the config reads `process.env`, keep (or add) `import 'dotenv/config';` as the
+         first import — the loader does not read `.env` for you.
+      4. In `package.json`, replace the `prisma-next` devDependency with `@prisma/cli@next`
+         plus `@prisma/cli-engine` at the exact version that `@prisma/cli` names in its own
+         dependencies, and rewrite scripts: `prisma-next <subcommand>` becomes
+         `prisma-cli <subcommand>` (`migration apply` becomes `migrate`; `init` alone moves
+         under the orm group as `prisma-cli orm init`).
+      5. Run `prisma-cli contract emit` to confirm the config loads and to regenerate the
+         artifacts (their generated-file headers change with this release).
+    detection:
+      glob: "**/prisma-next.config.ts"
+  - id: raw-moves-to-its-own-lane
+    summary: |
+      Whole-query raw SQL moves address: ``db.sql.raw`SELECT ...` `` becomes
+      ``db.raw.sql`SELECT ...` ``. Everything after the template is unchanged.
+      `.returnsRow(spec)`, `.affectedCount()`, `.returns(codecId)`, and splicing a
+      row-returning statement into another template all behave as they did.
+
+      The client's `raw` property changes shape in the same move. It was a tagged template you
+      could call directly for an expression fragment. It is now the raw lane, an object whose
+      `sql` key holds the statement tag.
+
+      An author who called `db.raw` as a fragment tag has two replacements. Use `fns.raw`
+      inside a builder callback, which is where fragments belong. Or terminate the lane's tag
+      with `.returns(codecId)` for the same expression, now bound to the contract.
+    detection:
+      glob: "**/*.{ts,tsx,mts,cts}"
+      regex:
+        # The old whole-query address, on any receiver.
+        - '\.sql\.raw`'
+        # The client tag being repurposed. `fns.raw` is a fragment call site and
+        # is deliberately excluded: fragments are unchanged by this release.
+        - '(?<!(?<![\w$])fns)\.raw`'
+      anyMatch: true
+  - id: raw-is-no-longer-a-reserved-namespace
+    summary: |
+      A storage namespace named `raw` is allowed again. 8.0.0-rc.2 and 8.0.0-rc.3 refused such a contract when
+      the client was built, with `ORM.NAMESPACE_RESERVED`, because the SQL surface answered
+      `db.sql.raw` with the raw tag. The tag has moved to `db.raw.sql`, so nothing a contract
+      declares can collide with it.
+
+      If you renamed a namespace to get past that error, you may rename it back:
+      `@@schema("raw")` is an ordinary name, reachable as `db.sql.raw.<table>`. Re-emit the
+      contract afterwards, then plan the rename against the database as you would any other
+      namespace rename. The physical schema keeps the name it has until a plan moves it.
+      Renaming back is optional: a namespace you renamed away stays valid.
+    detection:
+      glob: "**/*.{prisma,json}"
+      contains:
+        - "ORM.NAMESPACE_RESERVED"
+        - '@@schema("raw")'
+      anyMatch: true
+  - id: contract-artifacts-restamp
+    summary: |
+      The emitted `contract.json` / `contract.d.ts` embed the toolchain version, which moves
+      to 8.0.0-rc.4. Run `contract emit` once after upgrading so the emitted artifacts match
+      the installed toolchain. This applies even to projects whose config needed no
+      migration — the restamp is independent of the config changes above.
+    detection:
+      glob: "**/contract.json"
+      contains:
+        - '"version": "8.0.0-rc.3"'
+---
+
+# 8.0.0-rc.3 → 8.0.0-rc.4 — User upgrade instructions
+
+## `raw-moves-to-its-own-lane`
+
+Whole-query raw SQL has its own front door. The tag that sat inside the namespace map is now a
+lane on the client:
+
+```ts
+// Before
+const plan = db.sql.raw`SELECT id, email FROM users WHERE id = ${1}`
+  .returnsRow({ id: users.columns.id, email: users.columns.email })
+  .build();
+
+// After
+const plan = db.raw.sql`SELECT id, email FROM users WHERE id = ${1}`
+  .returnsRow({ id: users.columns.id, email: users.columns.email })
+  .build();
+```
+
+Everything after the template is unchanged: the terminators, the row specs they take, the plans
+they build, and splicing a row-returning statement into another template.
+
+The client's `raw` property changes shape in the same move. It was the expression tag you could
+call directly; it is now the lane, whose `sql` key holds the statement tag:
+
+```ts
+// Before: `raw` is a tag
+const upper = db.raw`UPPER(${email})`.returns('pg/text@1');
+
+// After, inside a builder callback — where fragments belong
+const rows = db.sql.public.users
+  .select((f, fns) => ({ upper: fns.raw`UPPER(${f.email})`.returns('pg/text@1') }))
+  .build();
+
+// After, from the lane, for a fragment you hold on its own
+const upper = db.raw.sql`UPPER(${email})`.returns('pg/text@1');
+```
+
+The detector looks for the old address and for `raw` used as a tag. It skips the receiver `fns`
+exactly, including `x.fns.raw`, because that is a fragment call site and needs no change. A
+receiver that merely ends in those letters, such as `myfns.raw`, still matches. So does a
+builder callback that names its functions object something else. Check whether the receiver is
+a client before you change anything.
+
+## `raw-is-no-longer-a-reserved-namespace`
+
+8.0.0-rc.2 and 8.0.0-rc.3 refused a contract whose storage declared a namespace named `raw`, because that was
+the key the SQL surface answered with the raw tag:
+
+```text
+ORM.NAMESPACE_RESERVED: The SQL surface exposes the raw statement tag as "db.raw", so a storage
+namespace named "raw" cannot be reached through it. Rename the namespace in the schema.
+```
+
+That constraint is gone. `db.sql` is a namespace map and nothing else, and the lane is composed
+by the client rather than derived from your contract, so the two cannot collide.
+
+If you renamed a namespace to get past the error, you may rename it back:
+
+```prisma
+model Event {
+  id String @id
+  @@schema("raw")
+}
+```
+
+Its tables are then reachable as `db.sql.raw.<table>`, like any other namespace. Re-emit the
+contract, and plan the rename against the database as you would any other namespace rename —
+the physical schema carries the old name until a plan moves it. Renaming back is optional; the
+name you moved to stays valid.

package/skills/prisma-8/upgrading/app/upgrades/8.0.0-rc.4-to-8.0.0-rc.5/instructions.md

@@ -0,0 +1,42 @@
+---
+from: "8.0.0-rc.4"
+to: "8.0.0-rc.5"
+changes:
+  - id: attach-pg-client-error-listener
+    summary: |
+      Attach an 'error' listener to any pg `Client` or `Pool` your own code constructs outside the Prisma runtime. node-postgres emits 'error' on the pool or client when an idle connection drops (database restart, pooler timeout, network blip); with no listener Node treats it as an uncaught exception and kills the process. Starting at rc.5 every pool and client the Prisma runtime creates or receives — including a pool you pass via the `pg:` binding — gets a listener automatically, so this only applies to pg handles your code uses directly (health checks, side-channel observers, hand-rolled scripts).
+    detection:
+      glob: "**/*.{ts,tsx}"
+      contains:
+        - "new Client("
+        - "new pg.Client("
+        - "new Pool("
+        - "new pg.Pool("
+      anyMatch: true
+  - id: contract-artifacts-restamp
+    summary: |
+      The emitted `contract.json` / `contract.d.ts` embed the toolchain version, which moves
+      to 8.0.0-rc.5. Run `contract emit` once after upgrading so the emitted artifacts match
+      the installed toolchain. The restamp is independent of the other changes in this
+      release.
+    detection:
+      glob: "**/contract.json"
+      contains:
+        - '"version": "8.0.0-rc.4"'
+---
+
+# 8.0.0-rc.4 → 8.0.0-rc.5 — User upgrade instructions
+
+## `attach-pg-client-error-listener`
+
+Walk every file matched by `detection.glob`. For each `pg.Client` or `pg.Pool` your code constructs and uses directly (not one handed to `postgres({ pg: ... })` / `supabase({ pg: ... })` — the runtime covers those since rc.5), attach an `'error'` listener right after construction, before `connect()`:
+
+```ts
+const client = new pg.Client({ connectionString });
+client.on('error', () => {});
+await client.connect();
+```
+
+A no-op listener is enough: connect and query failures still reject their own promises, so nothing real is masked — the listener only stops a dropped idle connection from becoming an uncaught exception. If the handle is long-lived and you have a logging channel, log the error instead of discarding it.
+
+Note that a surrounding `try/catch` does **not** cover this case — the `'error'` event is emitted on the client object asynchronously, outside any promise chain the `catch` can see.

package/skills/prisma-8/upgrading/extension/upgrades/0.10-to-0.11/instructions.md

@@ -0,0 +1,276 @@
+---
+from: "0.10"
+to: "0.11"
+changes:
+  - id: namespace-kind-required-on-handcrafted-contract-literals
+    summary: Add the `kind` discriminator (`'sql-namespace'` for SQL namespaces; `'mongo-namespace'` for Mongo namespaces) to every handcrafted `Contract<{ namespaces: { ... } }>` type literal in extension test-d files and inline-typed fixtures. The framework `Namespace` interface tightened `kind` from optional to required; emitted `contract.d.ts` literals carry it automatically, but anything you write by hand will fail typecheck without it.
+    detection:
+      glob: "**/*.test-d.ts"
+      contains:
+        - "Contract<"
+        - "namespaces"
+      anyMatch: true
+  - id: facade-add-close-and-async-dispose
+    summary: |
+      The official Prisma Next facades (`@internal/postgres`, `@internal/sqlite`, `@internal/mongo`) now expose `close()` and `[Symbol.asyncDispose]` so short-lived scripts can release facade-owned resources cleanly and exit instead of hanging on a live connection. Extensions that expose a facade in the same shape should add the same surface for parity, honouring the ownership rule (only close resources the facade itself constructed) and managing a terminal closed state (subsequent operations reject with a clear error). No script — manual code authoring per extension.
+    detection:
+      glob: "**/src/runtime/*.ts"
+      contains:
+        - "createRuntimeCore"
+      anyMatch: true
+  - id: mongo-close-ownership-rule
+    summary: |
+      The Mongo facade's `db.close()` is **silently breaking**. Before 0.11 it unconditionally called `await runtime.close()`, which closed the underlying `MongoClient` regardless of how the facade was constructed. From 0.11 it honours the ownership rule and closes only facade-constructed clients (from a `{ url }` binding); when the facade was constructed with `{ mongoClient }` the caller-supplied `MongoClient` is left untouched. Extensions that wrap or extend `@internal/mongo` and relied on `db.close()` disposing of a shared `MongoClient` need to either switch to a `{ url }` binding (so the facade owns the client) or close the `MongoClient` themselves.
+    detection:
+      glob: "**/*.{ts,tsx}"
+      contains:
+        - "mongoClient"
+        - "@internal/mongo"
+      anyMatch: true
+  - id: insert-single-row-wrap-in-array
+    summary: Wrap single-row `.insert({...})` call sites in an array — `.insert([{...}])`. The single-object overload is removed; `.insert()` now exclusively accepts an array of row objects.
+    detection:
+      glob: "**/*.{ts,tsx}"
+      contains:
+        - ".insert("
+      anyMatch: true
+  - id: insert-ast-with-values-to-with-rows
+    summary: Replace `InsertAst.withValues(assignments)` with `InsertAst.withRows([assignments])`. The `withValues` method is removed; `withRows` accepts an array of assignment maps.
+    detection:
+      glob: "**/*.{ts,tsx}"
+      contains:
+        - ".withValues("
+---
+
+# 0.10 → 0.11 — Extension-author upgrade instructions
+
+## `namespace-kind-required-on-handcrafted-contract-literals`
+
+Starting at the 0.11 release, the framework `Namespace` interface tightens `kind` from optional (inherited from `IRNode`) to required. Any **handcrafted** `Contract<{ namespaces: { ... } }>` type literal — typically used in extension test-d files and inline-typed fixtures — must add `kind: 'sql-namespace'` (or `'mongo-namespace'`) to each namespace literal or TypeScript will reject the literal as not structurally assignable to `Namespace`.
+
+This **does not** affect:
+
+- Real `contract.d.ts` files emitted by `prisma-next contract emit`. The emitter prints `kind` automatically.
+- Real `contract.json` envelopes. The runtime `kind` field is non-enumerable on namespace class instances, so it doesn't surface in the JSON on-disk envelope and the byte hash is unchanged.
+- Plain-literal `Contract` values constructed at runtime (the framework only tightens the **type** declaration of `kind`; the runtime walks tolerate missing values).
+
+It **does** affect:
+
+- `.test-d.ts` files in extension packages that handcraft `Contract<{ namespaces: { __unbound__: { id, tables, ... } } }>` literals to assert generic-inference shapes. Each namespace literal needs `kind: 'sql-namespace'` (SQL namespaces) or `kind: 'mongo-namespace'` (Mongo namespaces) added alongside `id`.
+- Any inline-typed fixture file (`test/fixtures/*.d.ts`, etc.) that mirrors what the emitter would produce for testing.
+
+### Before 0.11
+
+```ts
+type ContractUnderTest = Contract<
+  SqlStorage<string> & {
+    readonly namespaces: {
+      readonly __unbound__: {
+        readonly id: '__unbound__';
+        readonly tables: {
+          readonly user: {
+            // ... columns, primaryKey, etc.
+          };
+        };
+      };
+    };
+    readonly storageHash: StorageHash;
+  },
+  // ...
+>;
+```
+
+### Starting at 0.11
+
+```ts
+type ContractUnderTest = Contract<
+  SqlStorage<string> & {
+    readonly namespaces: {
+      readonly __unbound__: {
+        readonly id: '__unbound__';
+        readonly kind: 'sql-namespace'; // ← new: required
+        readonly tables: {
+          readonly user: {
+            // ... columns, primaryKey, etc.
+          };
+        };
+      };
+    };
+    readonly storageHash: StorageHash;
+  },
+  // ...
+>;
+```
+
+### Mapping table
+
+| Namespace family | Discriminator literal | Where it surfaces in handcrafted types |
+|---|---|---|
+| SQL (`SqlNamespace`, `SqlUnboundNamespace`) | `'sql-namespace'` | Anywhere you write `Contract<{ namespaces: { … } }>` with a SQL-style namespace |
+| Mongo (`MongoNamespace`, `MongoUnboundNamespace`) | `'mongo-namespace'` | Anywhere you write `Contract<{ namespaces: { … } }>` with a Mongo-style namespace |
+| Postgres (`PostgresSchema`, when handcrafted) | `'postgres-schema'` or `'postgres-unbound-schema'` | Rare in extension code; only needed if you handcraft a literal with a Postgres-specific namespace class |
+
+### Detection
+
+Run the matcher's grep over your extension's source:
+
+```bash
+rg --files-with-matches -t ts -e 'Contract<' -e 'namespaces' -g '**/*.test-d.ts'
+```
+
+For each match, open the file and add the `kind` literal to every namespace entry under `namespaces:`. If you have many such literals, a regex-driven mechanical pass works (e.g. find every `readonly id: '<ns-id>';` inside a `namespaces:` block and inject `readonly kind: 'sql-namespace';` immediately after).
+
+### Why the change
+
+The framework needs every namespace IR node to carry its family discriminator at the type level so that cross-family namespace walks (the new `elementCoordinates(storage)` surface in `@internal/framework-components/ir`) can dispatch on a known-present `kind`, not an optional one.
+
+The runtime invariant has always held — every concrete namespace class sets `kind` non-enumerably via `Object.defineProperty(this, 'kind', { value, enumerable: false })` in its constructor. The type tightening makes the invariant honest at the consumer surface.
+
+### What you do **not** need to change
+
+- No `.d.ts` regeneration is needed. Run `prisma-next contract emit` only as part of your normal authoring flow; the emitter handles the `kind` field for you.
+- No `contract.json` snapshot changes. The hash inputs are unchanged because `kind` is non-enumerable on namespace class instances.
+- No runtime API changes. Extension factories that construct namespaces via `new SqlStorage(...)`, `new PostgresSchema(...)`, etc. are unchanged — the constructors continue to materialise `kind` non-enumerably.
+
+## `facade-add-close-and-async-dispose`
+
+Starting at the 0.11 release the three official facades (`postgres()`, `sqlite()`, `mongo()`) expose two new methods:
+
+```typescript
+interface ClientFacade {
+  // ...existing surface...
+  close(): Promise<void>;
+  [Symbol.asyncDispose](): Promise<void>;
+}
+```
+
+This is the surface that lets a short-lived script (`tsx my-script.ts`) release facade-owned connection resources and exit cleanly. Without it, a `pg.Pool` (or analogous keep-alive in SQLite / Mongo) keeps Node's event loop alive and the script hangs after its last query prints.
+
+If your extension exposes a facade in the same shape (e.g. you publish your own `postgresServerless()` or `someDriver()` factory that returns the same client object), add the equivalent surface. Three load-bearing properties:
+
+1. **Ownership rule.** `close()` releases only the resources the facade *itself* constructed. A `{ url }` (or similar opaque-string) binding means the facade opened the connection — facade owns it, `close()` disposes it. A `{ pool }` / `{ client }` / `{ mongoClient }` (caller-supplied opaque-handle) binding means the caller owns it — `close()` leaves it untouched. The facade must capture this ownership decision at construction time and remember it.
+
+2. **Idempotence.** `close()` can be called multiple times in a row without throwing. The second and later calls are no-ops.
+
+3. **Terminal closed state.** After `close()` resolves, the facade is permanently locked. Any subsequent `db.orm.X.<op>(...)`, `db.runtime()`, `db.connect()` call rejects with `Error('<target> client is closed')`. This catches use-after-close bugs cleanly instead of silently re-opening resources.
+
+Reference implementations in this repo:
+
+- `packages/3-extensions/postgres/src/runtime/postgres.ts` (full pattern; `{ url }` vs `{ pool }` ownership)
+- `packages/3-extensions/sqlite/src/runtime/sqlite.ts` (only-`{ path }` shape; the facade always owns)
+- `packages/3-extensions/mongo/src/runtime/mongo.ts` (`{ url }` vs `{ mongoClient }`)
+
+The `[Symbol.asyncDispose]` alias is one line — delegate to `close()` — and enables the TS 5.2+ `await using db = yourFacade(...)` syntax. There is no good reason not to add both methods together.
+
+## `mongo-close-ownership-rule`
+
+Before 0.11, `@internal/mongo`'s `db.close()` looked like this:
+
+```typescript
+async close() {
+  try {
+    await runtimePromise;
+    await runtime.close();  // unconditional — closed any MongoClient, owned or not
+  } catch { /* swallow */ }
+  closed = true;
+}
+```
+
+From 0.11 it captures the ownership decision at construction time and only closes the `MongoClient` if the facade owns it:
+
+```typescript
+let ownedDispose: (() => Promise<void>) | undefined;
+if (resolvedBinding.kind === 'url') {
+  ownedDispose = () => driver.close();
+}
+// ...
+async close() {
+  try {
+    await runtimePromise;
+    await ownedDispose?.();  // no-op when the caller supplied the MongoClient
+  } catch { /* swallow */ }
+  closed = true;
+}
+```
+
+**If your extension uses `mongo({ mongoClient: someClient })`** and previously called `db.close()` expecting `someClient` to be closed, your test suite will now show the `MongoClient` outliving the facade. Two ways to migrate:
+
+- **Switch to a `{ url }` binding.** If your extension constructs the `MongoClient` purely to hand it to `mongo()`, drop the manual construction — pass the connection string in `{ url }` and let the facade own the client.
+- **Close the `MongoClient` explicitly.** If your extension genuinely needs to share a `MongoClient` across multiple consumers (e.g. one client backs several `mongo()` facades, or the client is held in a higher-level connection-management seam), keep the `{ mongoClient }` binding and add `await someClient.close()` after your last facade is disposed.
+
+No script — the right migration depends on why your extension was sharing the client in the first place. Walk the call sites by hand.
+
+## `insert-single-row-wrap-in-array`
+
+Starting at the 0.11 release, the `.insert()` method on the SQL builder accepts **only** an array of row objects. The single-object overload that previously allowed `.insert({ field: value })` is removed.
+
+Before 0.11:
+
+```ts
+const ast = InsertAst.into(TableSource.named(tableName))
+  .insert({ field: value });
+// or via the query builder:
+db.sql.table.insert({ field: value }).build();
+```
+
+Starting at 0.11:
+
+```ts
+const ast = InsertAst.into(TableSource.named(tableName))
+  .insert([{ field: value }]);
+// or via the query builder:
+db.sql.table.insert([{ field: value }]).build();
+```
+
+Walk every `.ts` / `.tsx` file matched by the `detection.glob` above. For each call site that passes a plain object directly to `.insert(...)`, wrap the argument in an array:
+
+- `.insert(row)` → `.insert([row])`
+- `.insert({ field: value })` → `.insert([{ field: value }])`
+
+Variable references to a row object are safe to wrap directly:
+
+```ts
+// Before
+await runtime.execute(db.sql.table.insert(row).build());
+// After
+await runtime.execute(db.sql.table.insert([row]).build());
+```
+
+If a call site already passes an array (`.insert([row1, row2])`), it is already correct — leave it unchanged.
+
+TypeScript will report bare-object call sites as type errors after the bump, which is a reliable compile-time signal for every affected site.
+
+## `insert-ast-with-values-to-with-rows`
+
+Starting at the 0.11 release, the `InsertAst.withValues(assignments)` method is removed. Extensions that build `InsertAst` directly via the AST layer must switch to `InsertAst.withRows([assignments])`.
+
+Before 0.11:
+
+```ts
+const ast = InsertAst.into(TableSource.named(tableName))
+  .withValues(createAssignments.assignments)
+  .withOnConflict(onConflict);
+```
+
+Starting at 0.11:
+
+```ts
+const ast = InsertAst.into(TableSource.named(tableName))
+  .withRows([createAssignments.assignments])
+  .withOnConflict(onConflict);
+```
+
+The change is:
+- Replace `.withValues(expr)` with `.withRows([expr])` — the single-row overload is removed; `withRows` accepts an array of assignment maps.
+
+Walk every `.ts` / `.tsx` file matched by the `detection.glob` above. For each call site matching `.withValues(`, apply the replacement. The argument remains a single expression; it just needs to be wrapped in an array.
+
+### Validation
+
+After applying the rules above, run `pnpm typecheck && pnpm test` (or your extension's equivalent). `prisma-8-check-pins` should also pass — the pin set is unchanged for this transition; the breaking change is in the `InsertAst` builder method surface, not the dependency contract.
+
+## Validation by execution
+
+These entries are prose-only (no scripts). The substrate diff on `packages/3-extensions/` is additive (new methods on the three official facades) plus the Mongo behaviour change documented above; the `namespace-kind-required-on-handcrafted-contract-literals` entry covers a type-only tightening with no runtime substrate transform. There is no codemod to apply against a reverted substrate — the framework changes *are* the new surfaces, and these instructions describe the consumer-side translation, not a substrate transform.
+
+The release-pipeline gate (`pnpm check:upgrade-coverage`) is satisfied by this directory existing with at least one entry. The substantive verification of the consumer-facing translation lives in the published skill's per-step bump-install-instructions-validate-commit loop, which runs in extension authors' own CI.