Skip to content

chore(deps): bump the metaobjects group across 1 directory with 6 updates#15

Closed
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/metaobjects-8fd40b1ca9
Closed

chore(deps): bump the metaobjects group across 1 directory with 6 updates#15
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/metaobjects-8fd40b1ca9

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jul 18, 2026

Copy link
Copy Markdown
Contributor

Bumps the metaobjects group with 6 updates in the / directory:

Package From To
@metaobjectsdev/cli 0.15.18 0.20.1
@metaobjectsdev/codegen-ts 0.15.18 0.20.1
@metaobjectsdev/render 0.15.18 0.20.1
@metaobjectsdev/runtime-ts 0.15.18 0.20.1
@metaobjectsdev/sdk 0.15.18 0.20.1
@metaobjectsdev/metadata 0.15.18 0.20.1

Updates @metaobjectsdev/cli from 0.15.18 to 0.20.1

Release notes

Sourced from @​metaobjectsdev/cli's releases.

v0.17.1

npm-only patch (0.17.0 → 0.17.1). Fixes the write-through-entity generated REST routes to read through the replica view, so read-your-writes returns the derived origin.passthrough field (#214) — the routes layer had been left on vanilla table CRUD. readView on runtime-ts mountCrudRoutes + codegen-ts routes wiring; gated by a new cross-port api-contract write-through corpus (TS/C#/Kotlin). PyPI/NuGet/Maven unchanged. See CHANGELOG.md [0.17.1].

0.15.21 — migrate-engine + wrong-row-write bug fixes; PK types derived, not hardcoded

Coordinated release: npm 0.15.21 · PyPI 0.15.13 · Maven Central 7.7.11. NuGet stays at 0.15.10 — the C# port needed no fix. It already derived the primary-key type correctly, and became the reference the other three ports were fixed against.

A bug-fix release, sourced from a downstream consumer's adoption report (TypeScript + Cloudflare D1 + uuid primary keys) and then widened by an adversarial review that hunted the same bug classes across the whole codebase. No metadata changes, no new vocabulary — existing metadata generates byte-identical output except where it was previously wrong.

Data loss and destructive migrations

  • Writable mounts performed a WRONG-ROW write/delete. On a TEXT/uuid primary key, DELETE /docs/0123 deleted row '123' (proven against real engines).
  • Every incremental meta migrate rebuilt every uuid-PK table — a false change-column-default that, on SQLite/D1, recreate-and-copies the whole table on every run, forever.
  • drop-view was auto-allowed — an extension's view or a hand-written view got an un-gated DROP VIEW.

Migrations that couldn't be applied, or silently did nothing

  • @autoSet emitted DEFAULT now() on SQLite/D1 — invalid SQL, so any entity with the standard createdAt @autoSet produced an un-appliable migration.
  • Changing field.enum @values never migrated on SQLite — meta migrate said "No schema changes" while production inserts kept violating the stale CHECK.
  • @kind: storedProc projections crashed meta migrate outright.
  • D1 introspection didn't exclude _cf_METADATA, aborting every second-and-later meta migrate --dialect d1.

Silently wrong SQL and types

  • The SQLite emitter dropped index @expr/@where/@orders — a partial UNIQUE index became a FULL UNIQUE constraint, silently rejecting valid inserts.
  • Boolean @default literals were quoted (DEFAULT 'false'), which SQLite stores as TEXT — so WHERE flag = 0 silently matched nothing.

Generated code hardcoded the primary-key type (Java, Kotlin, Python)

An entity declaring @generation: uuid got broken output while its own DTO correctly used UUID. Kotlin's generated code did not even compile. Java rejected uuid path vars with 400; Python's FastAPI router 422'd them before the handler ran. Not a metamodel gap — each port already had the type mapper and was using it a few lines away.

Note

Every migrate fix is now gated by an emit → apply to a real engine → introspect → re-diff must be EMPTY round-trip plus value-semantics probes. The absence of that gate — nothing ever ran the pipeline twice against a real database — is what let this whole class survive a large test suite. Two goldens were found to be encoding the bugs they pinned.

Full detail: CHANGELOG

Changelog

Sourced from @​metaobjectsdev/cli's changelog.

[0.20.1] — 2026-07-25

npm 0.20.1 (patch; NuGet 0.19.3 / PyPI 0.19.5 / Maven 7.11.3 unchanged). meta init quickstart polish: the post-init next-steps no longer lists the working meta gen / meta docs under "ship in later sub-projects" (only ingest/serve/install-hooks are unshipped), and meta init now scaffolds a minimal root .gitignore (node_modules/, *.sqlite, dist/) when the project has none, so a git add -A right after init does not stage node_modules or a local dev DB. No API or codegen-output change.

[0.20.0] — 2026-07-25

npm 0.20.0 only (NuGet stays at 0.19.3, PyPI at 0.19.4, Maven Central at 7.11.3 — those ports have no changed product file). Two first-touch quickstart UX fixes surfaced by a fresh-external-install pressure test; no new vocabulary. MINOR because the codegen import-extension default changes generated output (see below) and relativeModuleSpecifier's signature gains a parameter.

  • meta migrate baseline no longer silently traps a greenfield project. An offline meta migrate baseline (without --from-db) derives its "already-applied" snapshot from your metadata, so on an empty/new database it recorded the entities' target shape as already applied — no CREATE TABLE was ever emitted and the generated server 500'd no such table, while the CLI reported success at every step. Now meta migrate baseline introspects the target --db and refuses (exit 2, writes no snapshot) when it can prove the database is empty; every other offline baseline still writes the snapshot but warns that it emits no DDL. The no-snapshot error hint, the meta gen success hint, and meta migrate --help all now route to the correct greenfield bootstrap — meta migrate --from-db --db <url> --dialect <d> --slug init --apply — instead of the baseline subcommand.
  • Generated relative imports are now Node-ESM / nodenext-safe by default. Generated code emitted un-extensioned relative imports (import { Author } from "./Author", from "../db"), which fail TS2835 under a stock tsc --init (module: nodenext) config — a wall of errors out of the box for a newcomer (the repo's own moduleResolution: "bundler" masked it). The codegen.extStyle default now flips from "none" to "js" (import … from "./Author.js"), and meta init scaffolds extStyle: "js". .js specifiers resolve correctly under both nodenext and bundler resolution, so the default is strictly more compatible; opt back out with extStyle: "none". A relative dbImport (e.g. ../db) is extensioned too (../db.js). This changes generated output — the next meta gen on an existing project adds .js to relative imports (three-way merge preserves your hand edits); pin extStyle: "none" to keep the prior output. Gated by a new nodenext compile gate that type-checks real generated output under a stock nodenext program (zero TS2835).

[PyPI 0.19.5] — 2026-07-25

PyPI 0.19.5 only (a Python-port docs republish; npm 0.20.0, NuGet 0.19.3, Maven Central 7.11.3 unchanged; no product-code change vs 0.19.4). Republishes the corrected server/python/README.md — the live PyPI project page had claimed the distribution ships a migrate module (it does not — schema is TS-owned, ADR-0015) and described the runtime as "SQLAlchemy Core" (it is a DB-API 2 ObjectManager over pg8000 / psycopg). PyPI versions are immutable, so a fresh version was required to update the page.

[0.19.4] — 2026-07-24

PyPI 0.19.4 · Maven Central 7.11.3. npm stays at 0.19.3 and NuGet at 0.19.3 — neither port has a changed product file in this release (the TypeScript and C# changes were test-harness/fixture only). No breaking changes, no new vocabulary. Extends the ADR-0045 field.timestamp @autoSet stamping guarantee from vanilla entities to the TPH (single-table discriminator) per-subtype API surface (#203 / #229).

Generated TPH controllers now stamp @autoSet (Java, Kotlin, Python). The TPH per-subtype write path is a separate code path in every port and had not inherited the vanilla ADR-0045 stamping: the generated Java Spring controller (emitTph delegated raw to the consumer repository interface with no stampForInsert), the Kotlin controller (bound @autoSet columns straight from the DTO — and would NPE on a @required autoSet column), and the Python FastAPI router (omitted the stamp lines) all shipped a deployed TPH API surface that silently dropped @autoSet. Each now stamps in the generated per-subtype create/update: a fresh row's onCreate and onUpdate columns are stamped from one captured now() (equal), a PATCH bumps every onUpdate column and never rewrites onCreate, and caller-supplied @autoSet values are ignored. @autoSet is excluded from each port's per-subtype settable/validated set so a POST need not supply the server-owned column. C# and TypeScript already stamped on the TPH path (EF route stamping / Zod schema transforms) — verified, no change. A subtype declaring its OWN @autoSet column (rather than inheriting from the shared base) is a documented non-goal, compile-safe across all ports. Gated cross-port by a new tph-autoset-patch scenario on the shared api-contract-conformance/tph corpus, on every port's generated TPH lane plus the TS/C# reference lanes. Output is byte-identical for a TPH hierarchy that declares no @autoSet field.

Vanilla (non-TPH) Java <Entity>Patch no longer lets a caller mutate a write-once @autoSet column. The Java SpringDtoGenerator's vanilla settable set excluded the primary key but not @autoSet columns, so an HTTP PATCH could overwrite a write-once onCreate timestamp. It now excludes @autoSet (matching the TPH overload and the Python fix in 0.19.3); the onUpdate column is still server-stamped on every PATCH via stampAutoSetOnUpdate.

Per-registry scope: PyPI carries the Python TPH router fix; Maven Central carries the Java (TPH controller + vanilla patch) and Kotlin (TPH controller) fixes; npm and NuGet are unchanged (no product file changed — C#/TS already stamped and only their cross-port test lanes were touched).

[0.19.3] — 2026-07-21

Coordinated across all four registries: npm 0.19.3 · NuGet 0.19.3 · PyPI 0.19.3 · Maven Central 7.11.2. No breaking changes, no new vocabulary. Completes the ADR-0044 payload-record collision-naming rollout (#219) across the remaining ports — the TypeScript and C# half shipped in 0.19.2.

Payload record naming is collision-scoped in Python, Java and Kotlin (#219 stages 2–3, #220). When two object.values share a bare short name across packages (acme::alpha::Note + acme::beta::Note, both reachable from one payload by fully-qualified @objectRef — valid metadata since ADR-0041/0042), each port's payload generator silently produced the wrong output: Python deduped nested classes by fqn(), which returns the bare name when a loaded object's own package is unset, collapsing the two Notes into one NotePayload and dropping the second shape; Java and Kotlin are one-file-per-record emitters, so both records were named NotePayload and written to the same path — the second silently clobbered the first, last-wins. All three now run ADR-0044's three-pass pipeline: an FQN-keyed reference-closure walk, then name assignment (bare <Short>Payload when unique in the artifact's collision domain — the module for Python, the output package for Java/Kotlin; a package-derived name such as AcmeAlphaNotePayload for every colliding member; hard failure with ERR_PAYLOAD_NAME_COLLISION if a derived name still collides), then emission through the name map. Not breaking — names change only where output was silently wrong; non-colliding output is byte-identical, pinned per port. The Kotlin xpkg-collision conformance test (#220) is upgraded from asserting a file exists to running the payload generator, asserting two distinct classes, and compiling the output.

ERR_PAYLOAD_NAME_COLLISION promoted to the shared error-code ledger (ADR-0044). Declared per-port locally through stages 1–3 so registering it before every port implemented the check couldn't redden a port on a code it didn't emit, the backstop code now joins fixtures/conformance/ERROR-CODES.json and the central registries that gate against it — TypeScript errors.ts (exact bidirectional agreement), Python errors.py (superset), Java ErrorCode.java (peer of ERR_VAR_NOT_ON_PAYLOAD).

Per-registry scope: PyPI carries the Python payload fix; Maven Central carries the Java + Kotlin payload fixes; npm carries the additive errors.ts ledger entry only (the TypeScript payload fix itself shipped in 0.19.2); NuGet is a version-parity bump — the C# payload fix and its local ERR_PAYLOAD_NAME_COLLISION shipped in 0.19.2 and the C# code is unchanged here.

[0.19.2] — 2026-07-20

npm 0.19.2 · NuGet 0.19.2. PyPI stays at 0.19.2 and Maven Central at 7.11.1 — neither port has a changed file in this release. No breaking changes, no new vocabulary.

Generated forms validated edits against the wrong schema, blocking most saves (#227). The generated <Entity>Form takes defaultValues — edit is a first-class mode — but resolved every submit against InsertSchema. InsertSchema optionals are .optional(): absent is fine, null is rejected. An edit, though, is seeded from a real row whose unset optional columns are all null. So editing any row holding a NULL optional was blocked outright: "Invalid input" appeared on fields the user never touched, handleSubmit never fired, and the save silently did nothing. Since most rows carry at least one unset optional, this broke most edits.

The resolver now switches on the same defaultValues presence that already distinguishes create from edit everywhere else in the template. That is the semantically correct pairing regardless of the bug: an edit submits a PATCH, so it validates against the PATCH schema — UpdateSchema (.optional().nullable()) still enforces min/max/enum on present keys, it just doesn't demand required keys the PATCH isn't sending (FR-035 present-key). TPH forms get the same .omit(discriminator) treatment on both schemas. Rejected: normalizing null → "" in defaultValues (destroys the was-null vs was-empty distinction #223's tristate needs, and feeds "" to controls like view.image that expect string | null), and loosening InsertSchema optionals to .nullable() (weakens create-path validation for every consumer, including the server route, to paper over a client-side mode-selection bug). Generated-output change — regenerate to pick it up; three-way merge preserves hand-edits. TS-only; no other port generates forms.

Three CLI/codegen fixes surfaced by building the canonical advanced-modeling example. Each was narrowly scoped and independently adopter-visible:

  • verify --codegen failed spuriously for any project using template-output generators. Its throwaway regen root didn't carry the project's templates/ directory forward, so render-helper() had nothing to resolve against and the drift check reported failure on a project with no drift.
  • A relative outDir resolved against the ambient process.cwd() instead of the resolved --cwd — in both meta gen's write path (runner.ts) and verify --codegen's read path (codegen-drift.ts). Invoking the CLI from anywhere other than the project root wrote generated code to the wrong place.
  • render-helper.ts didn't stripPackage() a resolved @payloadRef before emitting it as a TypeScript identifier, producing invalid syntax for any payload declared in a named package.

Payload record emission is FQN-keyed with collision-scoped naming — TypeScript and C# (ADR-0044, #219). Two object.values sharing a short name across packages could not both be emitted. TypeScript resolved @objectRef correctly (ADR-0042) but then deduped already-emitted interfaces by bare name, silently dropping the second (first-wins). C# was worse: it stripped the package before resolution and looked the name up in a bare-name-only scan, so the two collapsed onto whichever the scan enumerated first — the wrong shape, silently.

... (truncated)

Commits
  • 6863b3f chore(release): npm 0.20.1 — meta init next-steps + root .gitignore
  • 253188c fix(cli,docs): quickstart polish — init next-steps, root .gitignore, py3.11 +...
  • 2f284ce chore(release): npm 0.20.0 — TS newcomer quickstart fixes (migrate trap + nod...
  • 6bbe307 fix(cli,codegen-ts): unblock the TS newcomer quickstart (migrate trap + noden...
  • b85ce88 chore(release): 0.19.3 (npm/NuGet) · 0.19.3 (PyPI) · 7.11.2 (Maven) — #219 st...
  • d75ad3f chore(release): 0.19.2 (npm) · 0.19.2 (NuGet) — #227 form edit schema, CLI fi...
  • 18e7116 feat(examples): canonical advanced-modeling spine (projections, entity views,...
  • 6a0cc96 chore(release): 0.19.1 (npm/NuGet) · 0.19.2 (PyPI) · 7.11.1 (Maven) — #224 @​m...
  • b3df8a5 feat(cli): verify --db can target Cloudflare D1 via --d1, and warns when file...
  • 9ecb34b chore(release): 0.19.0
  • Additional commits viewable in compare view

Updates @metaobjectsdev/codegen-ts from 0.15.18 to 0.20.1

Release notes

Sourced from @​metaobjectsdev/codegen-ts's releases.

v0.17.1

npm-only patch (0.17.0 → 0.17.1). Fixes the write-through-entity generated REST routes to read through the replica view, so read-your-writes returns the derived origin.passthrough field (#214) — the routes layer had been left on vanilla table CRUD. readView on runtime-ts mountCrudRoutes + codegen-ts routes wiring; gated by a new cross-port api-contract write-through corpus (TS/C#/Kotlin). PyPI/NuGet/Maven unchanged. See CHANGELOG.md [0.17.1].

0.15.21 — migrate-engine + wrong-row-write bug fixes; PK types derived, not hardcoded

Coordinated release: npm 0.15.21 · PyPI 0.15.13 · Maven Central 7.7.11. NuGet stays at 0.15.10 — the C# port needed no fix. It already derived the primary-key type correctly, and became the reference the other three ports were fixed against.

A bug-fix release, sourced from a downstream consumer's adoption report (TypeScript + Cloudflare D1 + uuid primary keys) and then widened by an adversarial review that hunted the same bug classes across the whole codebase. No metadata changes, no new vocabulary — existing metadata generates byte-identical output except where it was previously wrong.

Data loss and destructive migrations

  • Writable mounts performed a WRONG-ROW write/delete. On a TEXT/uuid primary key, DELETE /docs/0123 deleted row '123' (proven against real engines).
  • Every incremental meta migrate rebuilt every uuid-PK table — a false change-column-default that, on SQLite/D1, recreate-and-copies the whole table on every run, forever.
  • drop-view was auto-allowed — an extension's view or a hand-written view got an un-gated DROP VIEW.

Migrations that couldn't be applied, or silently did nothing

  • @autoSet emitted DEFAULT now() on SQLite/D1 — invalid SQL, so any entity with the standard createdAt @autoSet produced an un-appliable migration.
  • Changing field.enum @values never migrated on SQLite — meta migrate said "No schema changes" while production inserts kept violating the stale CHECK.
  • @kind: storedProc projections crashed meta migrate outright.
  • D1 introspection didn't exclude _cf_METADATA, aborting every second-and-later meta migrate --dialect d1.

Silently wrong SQL and types

  • The SQLite emitter dropped index @expr/@where/@orders — a partial UNIQUE index became a FULL UNIQUE constraint, silently rejecting valid inserts.
  • Boolean @default literals were quoted (DEFAULT 'false'), which SQLite stores as TEXT — so WHERE flag = 0 silently matched nothing.

Generated code hardcoded the primary-key type (Java, Kotlin, Python)

An entity declaring @generation: uuid got broken output while its own DTO correctly used UUID. Kotlin's generated code did not even compile. Java rejected uuid path vars with 400; Python's FastAPI router 422'd them before the handler ran. Not a metamodel gap — each port already had the type mapper and was using it a few lines away.

Note

Every migrate fix is now gated by an emit → apply to a real engine → introspect → re-diff must be EMPTY round-trip plus value-semantics probes. The absence of that gate — nothing ever ran the pipeline twice against a real database — is what let this whole class survive a large test suite. Two goldens were found to be encoding the bugs they pinned.

Full detail: CHANGELOG

Changelog

Sourced from @​metaobjectsdev/codegen-ts's changelog.

[0.20.1] — 2026-07-25

npm 0.20.1 (patch; NuGet 0.19.3 / PyPI 0.19.5 / Maven 7.11.3 unchanged). meta init quickstart polish: the post-init next-steps no longer lists the working meta gen / meta docs under "ship in later sub-projects" (only ingest/serve/install-hooks are unshipped), and meta init now scaffolds a minimal root .gitignore (node_modules/, *.sqlite, dist/) when the project has none, so a git add -A right after init does not stage node_modules or a local dev DB. No API or codegen-output change.

[0.20.0] — 2026-07-25

npm 0.20.0 only (NuGet stays at 0.19.3, PyPI at 0.19.4, Maven Central at 7.11.3 — those ports have no changed product file). Two first-touch quickstart UX fixes surfaced by a fresh-external-install pressure test; no new vocabulary. MINOR because the codegen import-extension default changes generated output (see below) and relativeModuleSpecifier's signature gains a parameter.

  • meta migrate baseline no longer silently traps a greenfield project. An offline meta migrate baseline (without --from-db) derives its "already-applied" snapshot from your metadata, so on an empty/new database it recorded the entities' target shape as already applied — no CREATE TABLE was ever emitted and the generated server 500'd no such table, while the CLI reported success at every step. Now meta migrate baseline introspects the target --db and refuses (exit 2, writes no snapshot) when it can prove the database is empty; every other offline baseline still writes the snapshot but warns that it emits no DDL. The no-snapshot error hint, the meta gen success hint, and meta migrate --help all now route to the correct greenfield bootstrap — meta migrate --from-db --db <url> --dialect <d> --slug init --apply — instead of the baseline subcommand.
  • Generated relative imports are now Node-ESM / nodenext-safe by default. Generated code emitted un-extensioned relative imports (import { Author } from "./Author", from "../db"), which fail TS2835 under a stock tsc --init (module: nodenext) config — a wall of errors out of the box for a newcomer (the repo's own moduleResolution: "bundler" masked it). The codegen.extStyle default now flips from "none" to "js" (import … from "./Author.js"), and meta init scaffolds extStyle: "js". .js specifiers resolve correctly under both nodenext and bundler resolution, so the default is strictly more compatible; opt back out with extStyle: "none". A relative dbImport (e.g. ../db) is extensioned too (../db.js). This changes generated output — the next meta gen on an existing project adds .js to relative imports (three-way merge preserves your hand edits); pin extStyle: "none" to keep the prior output. Gated by a new nodenext compile gate that type-checks real generated output under a stock nodenext program (zero TS2835).

[PyPI 0.19.5] — 2026-07-25

PyPI 0.19.5 only (a Python-port docs republish; npm 0.20.0, NuGet 0.19.3, Maven Central 7.11.3 unchanged; no product-code change vs 0.19.4). Republishes the corrected server/python/README.md — the live PyPI project page had claimed the distribution ships a migrate module (it does not — schema is TS-owned, ADR-0015) and described the runtime as "SQLAlchemy Core" (it is a DB-API 2 ObjectManager over pg8000 / psycopg). PyPI versions are immutable, so a fresh version was required to update the page.

[0.19.4] — 2026-07-24

PyPI 0.19.4 · Maven Central 7.11.3. npm stays at 0.19.3 and NuGet at 0.19.3 — neither port has a changed product file in this release (the TypeScript and C# changes were test-harness/fixture only). No breaking changes, no new vocabulary. Extends the ADR-0045 field.timestamp @autoSet stamping guarantee from vanilla entities to the TPH (single-table discriminator) per-subtype API surface (#203 / #229).

Generated TPH controllers now stamp @autoSet (Java, Kotlin, Python). The TPH per-subtype write path is a separate code path in every port and had not inherited the vanilla ADR-0045 stamping: the generated Java Spring controller (emitTph delegated raw to the consumer repository interface with no stampForInsert), the Kotlin controller (bound @autoSet columns straight from the DTO — and would NPE on a @required autoSet column), and the Python FastAPI router (omitted the stamp lines) all shipped a deployed TPH API surface that silently dropped @autoSet. Each now stamps in the generated per-subtype create/update: a fresh row's onCreate and onUpdate columns are stamped from one captured now() (equal), a PATCH bumps every onUpdate column and never rewrites onCreate, and caller-supplied @autoSet values are ignored. @autoSet is excluded from each port's per-subtype settable/validated set so a POST need not supply the server-owned column. C# and TypeScript already stamped on the TPH path (EF route stamping / Zod schema transforms) — verified, no change. A subtype declaring its OWN @autoSet column (rather than inheriting from the shared base) is a documented non-goal, compile-safe across all ports. Gated cross-port by a new tph-autoset-patch scenario on the shared api-contract-conformance/tph corpus, on every port's generated TPH lane plus the TS/C# reference lanes. Output is byte-identical for a TPH hierarchy that declares no @autoSet field.

Vanilla (non-TPH) Java <Entity>Patch no longer lets a caller mutate a write-once @autoSet column. The Java SpringDtoGenerator's vanilla settable set excluded the primary key but not @autoSet columns, so an HTTP PATCH could overwrite a write-once onCreate timestamp. It now excludes @autoSet (matching the TPH overload and the Python fix in 0.19.3); the onUpdate column is still server-stamped on every PATCH via stampAutoSetOnUpdate.

Per-registry scope: PyPI carries the Python TPH router fix; Maven Central carries the Java (TPH controller + vanilla patch) and Kotlin (TPH controller) fixes; npm and NuGet are unchanged (no product file changed — C#/TS already stamped and only their cross-port test lanes were touched).

[0.19.3] — 2026-07-21

Coordinated across all four registries: npm 0.19.3 · NuGet 0.19.3 · PyPI 0.19.3 · Maven Central 7.11.2. No breaking changes, no new vocabulary. Completes the ADR-0044 payload-record collision-naming rollout (#219) across the remaining ports — the TypeScript and C# half shipped in 0.19.2.

Payload record naming is collision-scoped in Python, Java and Kotlin (#219 stages 2–3, #220). When two object.values share a bare short name across packages (acme::alpha::Note + acme::beta::Note, both reachable from one payload by fully-qualified @objectRef — valid metadata since ADR-0041/0042), each port's payload generator silently produced the wrong output: Python deduped nested classes by fqn(), which returns the bare name when a loaded object's own package is unset, collapsing the two Notes into one NotePayload and dropping the second shape; Java and Kotlin are one-file-per-record emitters, so both records were named NotePayload and written to the same path — the second silently clobbered the first, last-wins. All three now run ADR-0044's three-pass pipeline: an FQN-keyed reference-closure walk, then name assignment (bare <Short>Payload when unique in the artifact's collision domain — the module for Python, the output package for Java/Kotlin; a package-derived name such as AcmeAlphaNotePayload for every colliding member; hard failure with ERR_PAYLOAD_NAME_COLLISION if a derived name still collides), then emission through the name map. Not breaking — names change only where output was silently wrong; non-colliding output is byte-identical, pinned per port. The Kotlin xpkg-collision conformance test (#220) is upgraded from asserting a file exists to running the payload generator, asserting two distinct classes, and compiling the output.

ERR_PAYLOAD_NAME_COLLISION promoted to the shared error-code ledger (ADR-0044). Declared per-port locally through stages 1–3 so registering it before every port implemented the check couldn't redden a port on a code it didn't emit, the backstop code now joins fixtures/conformance/ERROR-CODES.json and the central registries that gate against it — TypeScript errors.ts (exact bidirectional agreement), Python errors.py (superset), Java ErrorCode.java (peer of ERR_VAR_NOT_ON_PAYLOAD).

Per-registry scope: PyPI carries the Python payload fix; Maven Central carries the Java + Kotlin payload fixes; npm carries the additive errors.ts ledger entry only (the TypeScript payload fix itself shipped in 0.19.2); NuGet is a version-parity bump — the C# payload fix and its local ERR_PAYLOAD_NAME_COLLISION shipped in 0.19.2 and the C# code is unchanged here.

[0.19.2] — 2026-07-20

npm 0.19.2 · NuGet 0.19.2. PyPI stays at 0.19.2 and Maven Central at 7.11.1 — neither port has a changed file in this release. No breaking changes, no new vocabulary.

Generated forms validated edits against the wrong schema, blocking most saves (#227). The generated <Entity>Form takes defaultValues — edit is a first-class mode — but resolved every submit against InsertSchema. InsertSchema optionals are .optional(): absent is fine, null is rejected. An edit, though, is seeded from a real row whose unset optional columns are all null. So editing any row holding a NULL optional was blocked outright: "Invalid input" appeared on fields the user never touched, handleSubmit never fired, and the save silently did nothing. Since most rows carry at least one unset optional, this broke most edits.

The resolver now switches on the same defaultValues presence that already distinguishes create from edit everywhere else in the template. That is the semantically correct pairing regardless of the bug: an edit submits a PATCH, so it validates against the PATCH schema — UpdateSchema (.optional().nullable()) still enforces min/max/enum on present keys, it just doesn't demand required keys the PATCH isn't sending (FR-035 present-key). TPH forms get the same .omit(discriminator) treatment on both schemas. Rejected: normalizing null → "" in defaultValues (destroys the was-null vs was-empty distinction #223's tristate needs, and feeds "" to controls like view.image that expect string | null), and loosening InsertSchema optionals to .nullable() (weakens create-path validation for every consumer, including the server route, to paper over a client-side mode-selection bug). Generated-output change — regenerate to pick it up; three-way merge preserves hand-edits. TS-only; no other port generates forms.

Three CLI/codegen fixes surfaced by building the canonical advanced-modeling example. Each was narrowly scoped and independently adopter-visible:

  • verify --codegen failed spuriously for any project using template-output generators. Its throwaway regen root didn't carry the project's templates/ directory forward, so render-helper() had nothing to resolve against and the drift check reported failure on a project with no drift.
  • A relative outDir resolved against the ambient process.cwd() instead of the resolved --cwd — in both meta gen's write path (runner.ts) and verify --codegen's read path (codegen-drift.ts). Invoking the CLI from anywhere other than the project root wrote generated code to the wrong place.
  • render-helper.ts didn't stripPackage() a resolved @payloadRef before emitting it as a TypeScript identifier, producing invalid syntax for any payload declared in a named package.

Payload record emission is FQN-keyed with collision-scoped naming — TypeScript and C# (ADR-0044, #219). Two object.values sharing a short name across packages could not both be emitted. TypeScript resolved @objectRef correctly (ADR-0042) but then deduped already-emitted interfaces by bare name, silently dropping the second (first-wins). C# was worse: it stripped the package before resolution and looked the name up in a bare-name-only scan, so the two collapsed onto whichever the scan enumerated first — the wrong shape, silently.

... (truncated)

Commits
  • 6863b3f chore(release): npm 0.20.1 — meta init next-steps + root .gitignore
  • 2f284ce chore(release): npm 0.20.0 — TS newcomer quickstart fixes (migrate trap + nod...
  • 6bbe307 fix(cli,codegen-ts): unblock the TS newcomer quickstart (migrate trap + noden...
  • b85ce88 chore(release): 0.19.3 (npm/NuGet) · 0.19.3 (PyPI) · 7.11.2 (Maven) — #219 st...
  • d75ad3f chore(release): 0.19.2 (npm) · 0.19.2 (NuGet) — #227 form edit schema, CLI fi...
  • 60e6880 fix(codegen-ts-react): validate edits against UpdateSchema, not InsertSchema ...
  • 89b10c3 fix(codegen): FQN-keyed payload record emission with collision-scoped naming ...
  • 18e7116 feat(examples): canonical advanced-modeling spine (projections, entity views,...
  • 6a0cc96 chore(release): 0.19.1 (npm/NuGet) · 0.19.2 (PyPI) · 7.11.1 (Maven) — #224 @​m...
  • fa712a4 feat(metamodel): an explicit validator.length @​min is authoritative over the ...
  • Additional commits viewable in compare view

Updates @metaobjectsdev/render from 0.15.18 to 0.20.1

Release notes

Sourced from @​metaobjectsdev/render's releases.

v0.17.1

npm-only patch (0.17.0 → 0.17.1). Fixes the write-through-entity generated REST routes to read through the replica view, so read-your-writes returns the derived origin.passthrough field (#214) — the routes layer had been left on vanilla table CRUD. readView on runtime-ts mountCrudRoutes + codegen-ts routes wiring; gated by a new cross-port api-contract write-through corpus (TS/C#/Kotlin). PyPI/NuGet/Maven unchanged. See CHANGELOG.md [0.17.1].

0.15.21 — migrate-engine + wrong-row-write bug fixes; PK types derived, not hardcoded

Coordinated release: npm 0.15.21 · PyPI 0.15.13 · Maven Central 7.7.11. NuGet stays at 0.15.10 — the C# port needed no fix. It already derived the primary-key type correctly, and became the reference the other three ports were fixed against.

A bug-fix release, sourced from a downstream consumer's adoption report (TypeScript + Cloudflare D1 + uuid primary keys) and then widened by an adversarial review that hunted the same bug classes across the whole codebase. No metadata changes, no new vocabulary — existing metadata generates byte-identical output except where it was previously wrong.

Data loss and destructive migrations

  • Writable mounts performed a WRONG-ROW write/delete. On a TEXT/uuid primary key, DELETE /docs/0123 deleted row '123' (proven against real engines).
  • Every incremental meta migrate rebuilt every uuid-PK table — a false change-column-default that, on SQLite/D1, recreate-and-copies the whole table on every run, forever.
  • drop-view was auto-allowed — an extension's view or a hand-written view got an un-gated DROP VIEW.

Migrations that couldn't be applied, or silently did nothing

  • @autoSet emitted DEFAULT now() on SQLite/D1 — invalid SQL, so any entity with the standard createdAt @autoSet produced an un-appliable migration.
  • Changing field.enum @values never migrated on SQLite — meta migrate said "No schema changes" while production inserts kept violating the stale CHECK.
  • @kind: storedProc projections crashed meta migrate outright.
  • D1 introspection didn't exclude _cf_METADATA, aborting every second-and-later meta migrate --dialect d1.

Silently wrong SQL and types

  • The SQLite emitter dropped index @expr/@where/@orders — a partial UNIQUE index became a FULL UNIQUE constraint, silently rejecting valid inserts.
  • Boolean @default literals were quoted (DEFAULT 'false'), which SQLite stores as TEXT — so WHERE flag = 0 silently matched nothing.

Generated code hardcoded the primary-key type (Java, Kotlin, Python)

An entity declaring @generation: uuid got broken output while its own DTO correctly used UUID. Kotlin's generated code did not even compile. Java rejected uuid path vars with 400; Python's FastAPI router 422'd them before the handler ran. Not a metamodel gap — each port already had the type mapper and was using it a few lines away.

Note

Every migrate fix is now gated by an emit → apply to a real engine → introspect → re-diff must be EMPTY round-trip plus value-semantics probes. The absence of that gate — nothing ever ran the pipeline twice against a real database — is what let this whole class survive a large test suite. Two goldens were found to be encoding the bugs they pinned.

Full detail: CHANGELOG

Changelog

Sourced from @​metaobjectsdev/render's changelog.

[0.20.1] — 2026-07-25

npm 0.20.1 (patch; NuGet 0.19.3 / PyPI 0.19.5 / Maven 7.11.3 unchanged). meta init quickstart polish: the post-init next-steps no longer lists the working meta gen / meta docs under "ship in later sub-projects" (only ingest/serve/install-hooks are unshipped), and meta init now scaffolds a minimal root .gitignore (node_modules/, *.sqlite, dist/) when the project has none, so a git add -A right after init does not stage node_modules or a local dev DB. No API or codegen-output change.

[0.20.0] — 2026-07-25

npm 0.20.0 only (NuGet stays at 0.19.3, PyPI at 0.19.4, Maven Central at 7.11.3 — those ports have no changed product file). Two first-touch quickstart UX fixes surfaced by a fresh-external-install pressure test; no new vocabulary. MINOR because the codegen import-extension default changes generated output (see below) and relativeModuleSpecifier's signature gains a parameter.

  • meta migrate baseline no longer silently traps a greenfield project. An offline meta migrate baseline (without --from-db) derives its "already-applied" snapshot from your metadata, so on an empty/new database it recorded the entities' target shape as already applied — no CREATE TABLE was ever emitted and the generated server 500'd no such table, while the CLI reported success at every step. Now meta migrate baseline introspects the target --db and refuses (exit 2, writes no snapshot) when it can prove the database is empty; every other offline baseline still writes the snapshot but warns that it emits no DDL. The no-snapshot error hint, the meta gen success hint, and meta migrate --help all now route to the correct greenfield bootstrap — meta migrate --from-db --db <url> --dialect <d> --slug init --apply — instead of the baseline subcommand.
  • Generated relative imports are now Node-ESM / nodenext-safe by default. Generated code emitted un-extensioned relative imports (import { Author } from "./Author", from "../db"), which fail TS2835 under a stock tsc --init (module: nodenext) config — a wall of errors out of the box for a newcomer (the repo's own moduleResolution: "bundler" masked it). The codegen.extStyle default now flips from "none" to "js" (import … from "./Author.js"), and meta init scaffolds extStyle: "js". .js specifiers resolve correctly under both nodenext and bundler resolution, so the default is strictly more compatible; opt back out with extStyle: "none". A relative dbImport (e.g. ../db) is extensioned too (../db.js). This changes generated output — the next meta gen on an existing project adds .js to relative imports (three-way merge preserves your hand edits); pin extStyle: "none" to keep the prior output. Gated by a new nodenext compile gate that type-checks real generated output under a stock nodenext program (zero TS2835).

[PyPI 0.19.5] — 2026-07-25

PyPI 0.19.5 only (a Python-port docs republish; npm 0.20.0, NuGet 0.19.3, Maven Central 7.11.3 unchanged; no product-code change vs 0.19.4). Republishes the corrected server/python/README.md — the live PyPI project page had claimed the distribution ships a migrate module (it does not — schema is TS-owned, ADR-0015) and described the runtime as "SQLAlchemy Core" (it is a DB-API 2 ObjectManager over pg8000 / psycopg). PyPI versions are immutable, so a fresh version was required to update the page.

[0.19.4] — 2026-07-24

PyPI 0.19.4 · Maven Central 7.11.3. npm stays at 0.19.3 and NuGet at 0.19.3 — neither port has a changed product file in this release (the TypeScript and C# changes were test-harness/fixture only). No breaking changes, no new vocabulary. Extends the ADR-0045 field.timestamp @autoSet stamping guarantee from vanilla entities to the TPH (single-table discriminator) per-subtype API surface (#203 / #229).

Generated TPH controllers now stamp @autoSet (Java, Kotlin, Python). The TPH per-subtype write path is a separate code path in every port and had not inherited the vanilla ADR-0045 stamping: the generated Java Spring controller (emitTph delegated raw to the consumer repository interface with no stampForInsert), the Kotlin controller (bound @autoSet columns straight from the DTO — and would NPE on a @required autoSet column), and the Python FastAPI router (omitted the stamp lines) all shipped a deployed TPH API surface that silently dropped @autoSet. Each now stamps in the generated per-subtype create/update: a fresh row's onCreate and onUpdate columns are stamped from one captured now() (equal), a PATCH bumps every onUpdate column and never rewrites onCreate, and caller-supplied @autoSet values are ignored. @autoSet is excluded from each port's per-subtype settable/validated set so a POST need not supply the server-owned column. C# and TypeScript already stamped on the TPH path (EF route stamping / Zod schema transforms) — verified, no change. A subtype declaring its OWN @autoSet column (rather than inheriting from the shared base) is a documented non-goal, compile-safe across all ports. Gated cross-port by a new tph-autoset-patch scenario on the shared api-contract-conformance/tph corpus, on every port's generated TPH lane plus the TS/C# reference lanes. Output is byte-identical for a TPH hierarchy that declares no @autoSet field.

Vanilla (non-TPH) Java <Entity>Patch no longer lets a caller mutate a write-once @autoSet column. The Java SpringDtoGenerator's vanilla settable set excluded the primary key but not @autoSet columns, so an HTTP PATCH could overwrite a write-once onCreate timestamp. It now excludes @autoSet (matching the TPH overload and the Python fix in 0.19.3); the onUpdate column is still server-stamped on every PATCH via stampAutoSetOnUpdate.

Per-registry scope: PyPI carries the Python TPH router fix; Maven Central carries the Java (TPH controller + vanilla patch) and Kotlin (TPH controller) fixes; npm and NuGet are unchanged (no product file changed — C#/TS already stamped and only their cross-port test lanes were touched).

[0.19.3] — 2026-07-21

Coordinated across all four registries: npm 0.19.3 · NuGet 0.19.3 · PyPI 0.19.3 · Maven Central 7.11.2. No breaking changes, no new vocabulary. Completes the ADR-0044 payload-record collision-naming rollout (#219) across the remaining ports — the TypeScript and C# half shipped in 0.19.2.

Payload record naming is collision-scoped in Python, Java and Kotlin (#219 stages 2–3, #220). When two object.values share a bare short name across packages (acme::alpha::Note + acme::beta::Note, both reachable from one payload by fully-qualified @objectRef — valid metadata since ADR-0041/0042), each port's payload generator silently produced the wrong output: Python deduped nested classes by fqn(), which returns the bare name when a loaded object's own package is unset, collapsing the two Notes into one NotePayload and dropping the second shape; Java and Kotlin are one-file-per-record emitters, so both records were named NotePayload and written to the same path — the second silently clobbered the first, last-wins. All three now run ADR-0044's three-pass pipeline: an FQN-keyed reference-closure walk, then name assignment (bare <Short>Payload when unique in the artifact's collision domain — the module for Python, the output package for Java/Kotlin; a package-derived name such as AcmeAlphaNotePayload for every colliding member; hard failure with ERR_PAYLOAD_NAME_COLLISION if a derived name still collides), then emission through the name map. Not breaking — names change only where output was silently wrong; non-colliding output is byte-identical, pinned per port. The Kotlin xpkg-collision conformance test (#220) is upgraded from asserting a file exists to running the payload generator, asserting two distinct classes, and compiling the output.

ERR_PAYLOAD_NAME_COLLISION promoted to the shared error-code ledger (ADR-0044). Declared per-port locally through stages 1–3 so registering it before every port implemented the check couldn't redden a port on a code it didn't emit, the backstop code now joins fixtures/conformance/ERROR-CODES.json and the central registries that gate against it — TypeScript errors.ts (exact bidirectional agreement), Python errors.py (superset), Java ErrorCode.java (peer of ERR_VAR_NOT_ON_PAYLOAD).

Per-registry scope: PyPI carries the Python payload fix; Maven Central carries the Java + Kotlin payload fixes; npm carries the additive errors.ts ledger entry only (the TypeScript payload fix itself shipped in 0.19.2); NuGet is a version-parity bump — the C# payload fix and its local ERR_PAYLOAD_NAME_COLLISION shipped in 0.19.2 and the C# code is unchanged here.

[0.19.2] — 2026-07-20

npm 0.19.2 · NuGet 0.19.2. PyPI stays at 0.19.2 and Maven Central at 7.11.1 — neither port has a changed file in this release. No breaking changes, no new vocabulary.

Generated forms validated edits against the wrong schema, blocking most saves (#227). The generated <Entity>Form takes defaultValues — edit is a first-class mode — but resolved every...

Description has been truncated

@dependabot dependabot Bot added dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code labels Jul 18, 2026
@dependabot dependabot Bot changed the title chore(deps): bump the metaobjects group with 6 updates chore(deps): bump the metaobjects group across 1 directory with 6 updates Jul 25, 2026
@dependabot
dependabot Bot force-pushed the dependabot/npm_and_yarn/metaobjects-8fd40b1ca9 branch from 3be77d0 to 758299e Compare July 25, 2026 13:33
…ates

Bumps the metaobjects group with 6 updates in the / directory:

| Package | From | To |
| --- | --- | --- |
| [@metaobjectsdev/cli](https://github.com/metaobjectsdev/metaobjects/tree/HEAD/server/typescript/packages/cli) | `0.15.18` | `0.20.1` |
| [@metaobjectsdev/codegen-ts](https://github.com/metaobjectsdev/metaobjects/tree/HEAD/server/typescript/packages/codegen-ts) | `0.15.18` | `0.20.1` |
| [@metaobjectsdev/render](https://github.com/metaobjectsdev/metaobjects/tree/HEAD/server/typescript/packages/render) | `0.15.18` | `0.20.1` |
| [@metaobjectsdev/runtime-ts](https://github.com/metaobjectsdev/metaobjects/tree/HEAD/server/typescript/packages/runtime-ts) | `0.15.18` | `0.20.1` |
| [@metaobjectsdev/sdk](https://github.com/metaobjectsdev/metaobjects/tree/HEAD/server/typescript/packages/sdk) | `0.15.18` | `0.20.1` |
| [@metaobjectsdev/metadata](https://github.com/metaobjectsdev/metaobjects/tree/HEAD/server/typescript/packages/metadata) | `0.15.18` | `0.20.1` |



Updates `@metaobjectsdev/cli` from 0.15.18 to 0.20.1
- [Release notes](https://github.com/metaobjectsdev/metaobjects/releases)
- [Changelog](https://github.com/metaobjectsdev/metaobjects/blob/main/CHANGELOG.md)
- [Commits](https://github.com/metaobjectsdev/metaobjects/commits/v0.20.1/server/typescript/packages/cli)

Updates `@metaobjectsdev/codegen-ts` from 0.15.18 to 0.20.1
- [Release notes](https://github.com/metaobjectsdev/metaobjects/releases)
- [Changelog](https://github.com/metaobjectsdev/metaobjects/blob/main/CHANGELOG.md)
- [Commits](https://github.com/metaobjectsdev/metaobjects/commits/v0.20.1/server/typescript/packages/codegen-ts)

Updates `@metaobjectsdev/render` from 0.15.18 to 0.20.1
- [Release notes](https://github.com/metaobjectsdev/metaobjects/releases)
- [Changelog](https://github.com/metaobjectsdev/metaobjects/blob/main/CHANGELOG.md)
- [Commits](https://github.com/metaobjectsdev/metaobjects/commits/v0.20.1/server/typescript/packages/render)

Updates `@metaobjectsdev/runtime-ts` from 0.15.18 to 0.20.1
- [Release notes](https://github.com/metaobjectsdev/metaobjects/releases)
- [Changelog](https://github.com/metaobjectsdev/metaobjects/blob/main/CHANGELOG.md)
- [Commits](https://github.com/metaobjectsdev/metaobjects/commits/v0.20.1/server/typescript/packages/runtime-ts)

Updates `@metaobjectsdev/sdk` from 0.15.18 to 0.20.1
- [Release notes](https://github.com/metaobjectsdev/metaobjects/releases)
- [Changelog](https://github.com/metaobjectsdev/metaobjects/blob/main/CHANGELOG.md)
- [Commits](https://github.com/metaobjectsdev/metaobjects/commits/v0.20.1/server/typescript/packages/sdk)

Updates `@metaobjectsdev/metadata` from 0.15.18 to 0.20.1
- [Release notes](https://github.com/metaobjectsdev/metaobjects/releases)
- [Changelog](https://github.com/metaobjectsdev/metaobjects/blob/main/CHANGELOG.md)
- [Commits](https://github.com/metaobjectsdev/metaobjects/commits/v0.20.1/server/typescript/packages/metadata)

---
updated-dependencies:
- dependency-name: "@metaobjectsdev/cli"
  dependency-version: 0.16.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: metaobjects
- dependency-name: "@metaobjectsdev/codegen-ts"
  dependency-version: 0.16.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: metaobjects
- dependency-name: "@metaobjectsdev/metadata"
  dependency-version: 0.16.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
  dependency-group: metaobjects
- dependency-name: "@metaobjectsdev/render"
  dependency-version: 0.16.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: metaobjects
- dependency-name: "@metaobjectsdev/runtime-ts"
  dependency-version: 0.16.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: metaobjects
- dependency-name: "@metaobjectsdev/sdk"
  dependency-version: 0.16.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: metaobjects
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/npm_and_yarn/metaobjects-8fd40b1ca9 branch from 758299e to d1896f2 Compare July 25, 2026 14:29
@github-actions
github-actions Bot enabled auto-merge (squash) July 25, 2026 14:29
dmealing added a commit that referenced this pull request Jul 25, 2026
Off the stale pin (4 minors + the breaking 0.16.0 behind). The bump surfaces one
owned-composer gap: codegen/generators/queries.ts (scaffold-and-own, ADR-0034,
frozen pre-FR-035) built the update-fn import line without <Entity>Patch /
<Entity>UpdateSchema, but calls the live renderUpdateFn which since FR-035 (0.16.0)
emits `patch: <Entity>Patch` + `<Entity>UpdateSchema.parse(patch)`. Added both
symbols to the owned import line, mirroring the engine's current vanilla composer.

Pinned extStyle:"none" — the repo compiles under moduleResolution:"Bundler", so the
0.20 default flip (none -> "js") would churn every generated import for no benefit.

Regenerated; the drift gate, tsc, production build, and the full 201-test suite are
all green. Supersedes dependabot #15.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XeGSV3StPCcJGZNNJ4ZfAb
@dmealing

Copy link
Copy Markdown
Member

Superseded — the @metaobjectsdev/* group was upgraded 0.15.18 → 0.20.1 directly on main in 87c0f86, together with the owned codegen/generators/queries.ts FR-035 import fix that this bump requires (present-key PATCH tristate). Drift gate, tsc, build, and the 201-test suite are all green on main. Closing.

@dependabot @github

dependabot Bot commented on behalf of github Jul 25, 2026

Copy link
Copy Markdown
Contributor Author

Looks like these dependencies are no longer updatable, so this is no longer needed.

@dmealing dmealing closed this Jul 25, 2026
auto-merge was automatically disabled July 25, 2026 14:49

Pull request was closed

@dependabot @github

dependabot Bot commented on behalf of github Jul 25, 2026

Copy link
Copy Markdown
Contributor Author

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml

@dependabot
dependabot Bot deleted the dependabot/npm_and_yarn/metaobjects-8fd40b1ca9 branch July 25, 2026 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file javascript Pull requests that update javascript code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant