chore(deps): bump the metaobjects group with 6 updates

[dependabot]

Bumps the metaobjects group with 6 updates:

Package	From	To
@metaobjectsdev/cli	0.20.11	0.21.6
@metaobjectsdev/codegen-ts	0.20.11	0.21.6
@metaobjectsdev/render	0.20.11	0.21.6
@metaobjectsdev/runtime-ts	0.20.11	0.21.6
@metaobjectsdev/sdk	0.20.11	0.21.6
@metaobjectsdev/metadata	0.20.11	0.21.6

Updates @metaobjectsdev/cli from 0.20.11 to 0.21.6

Changelog

Sourced from @​metaobjectsdev/cli's changelog.

[0.21.6] — npm 0.21.6 · PyPI 0.21.6 · NuGet 0.21.6 · Maven 7.21.6

A coordinated PATCH across all four registries. Two changes alter runtime behaviour on an existing database — read these two before upgrading:

Who this reaches, and when. Neither change is retroactive: nothing happens to a running deployment until you deliberately install 0.21.6. If you depend on ^0.21.x, a routine npm update will pick it up — that is the case to plan for. If you pin exactly ("0.21.5"), you move only on purpose, and nothing below has already happened to you.

1. like is now case-SENSITIVE on Postgres (it was dispatching ILIKE). FR-009 always specified SQL LIKE, and TS's own persistence drivers were already case-sensitive — only one branch of one HTTP parser disagreed, so a query returning extra rows today will return fewer after upgrading. Case-insensitive matching stays available via ?search; an ilike operator remains deliberately unadded (ADR-0049).
2. The first meta migrate after upgrading emits a migration ADDING ON DELETE actions to live foreign keys. A parent-side relationship.composition was silently contributing no referential action; it now contributes its subtype default. This changes production delete semantics — pin @onDelete: "no-action" on the reference to keep current DB behaviour (ADR-0047).

Both are corrections of previously-wrong behaviour rather than contract changes, which is why this is a PATCH — the same call, on the same class of defect, as the Java LIKE fix in 0.21.4.

Fixed — parent-side relationship.composition reaches the child's FK (migrate-ts; ADR-0047)

ADOPTER-VISIBLE MIGRATION — production delete semantics change. After upgrading, the first meta migrate against a live database emits a one-time migration adding ON DELETE CASCADE (or the relationship's declared/default action) to FKs whose parent-side relationship was previously silently ignored — deleting a parent row then deletes its children instead of failing. This is the documented semantic the metadata always declared, but it was never enforced, so review that migration deliberately; pin @onDelete: "no-action" on any relationship whose DB behavior you want kept. The same applies to a child-side relationship authored with an FQN @objectRef, which the old exact-string correlation silently missed. Give this entry top billing at cut time.

The authoring the docs and the metaobjects-authoring skill teach — declaring the relationship on the PARENT (relationship.composition { @objectRef: "Post", @cardinality: "many" } on Author, with the subtype implying the default action) — contributed nothing to the foreign key: resolveReferentialActions correlated only relationships declared on the FK-owning child, so the documented "composition ⇒ ON DELETE CASCADE default" never fired and deleting a parent with children was a raw FK violation at runtime. The resolver now correlates the reverse relationship on the target entity as a third precedence tier (reference-level attr → child-side relationship → parent-side relationship; each relationship contributing its explicit action, else its subtype default). Tier-2 correlation is now package-aware

... (truncated)

Commits

• fdb8fa4 chore(release): 0.21.6 coordinated (npm/PyPI/NuGet 0.21.6 · Maven 7.21.6)
• b90b693 Merge branch 'worktree-agent-a2ba85024edf22bd0'
• 9787147 test: give all 55 vacuous no-argument toThrow() assertions error identity
• 2f2d834 fix(codegen-ts,cli): duplicate imports in generated files under a split ts-po...
• 65b0181 chore(release): 0.21.5 coordinated (npm/PyPI/NuGet 0.21.5 · Maven 7.21.5)
• 0565c39 fix(cli): meta init left a project whose first tsc failed with 94 errors
• 2c690e0 fix: bound every peer range, and stop emitting artifacts for sourceless objects
• 3948bb9 chore(release): 0.21.4 coordinated (npm/PyPI/NuGet 0.21.4 · Maven 7.21.4)
• 97485f6 fix(cli): make meta gen --dry-run actually preview
• 37a7d13 fix(cli): stop leaking a mutated Error.prepareStackTrace from config loading
• Additional commits viewable in compare view

Updates @metaobjectsdev/codegen-ts from 0.20.11 to 0.21.6

Changelog

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

[0.21.6] — npm 0.21.6 · PyPI 0.21.6 · NuGet 0.21.6 · Maven 7.21.6

A coordinated PATCH across all four registries. Two changes alter runtime behaviour on an existing database — read these two before upgrading:

Who this reaches, and when. Neither change is retroactive: nothing happens to a running deployment until you deliberately install 0.21.6. If you depend on ^0.21.x, a routine npm update will pick it up — that is the case to plan for. If you pin exactly ("0.21.5"), you move only on purpose, and nothing below has already happened to you.

1. like is now case-SENSITIVE on Postgres (it was dispatching ILIKE). FR-009 always specified SQL LIKE, and TS's own persistence drivers were already case-sensitive — only one branch of one HTTP parser disagreed, so a query returning extra rows today will return fewer after upgrading. Case-insensitive matching stays available via ?search; an ilike operator remains deliberately unadded (ADR-0049).
2. The first meta migrate after upgrading emits a migration ADDING ON DELETE actions to live foreign keys. A parent-side relationship.composition was silently contributing no referential action; it now contributes its subtype default. This changes production delete semantics — pin @onDelete: "no-action" on the reference to keep current DB behaviour (ADR-0047).

Both are corrections of previously-wrong behaviour rather than contract changes, which is why this is a PATCH — the same call, on the same class of defect, as the Java LIKE fix in 0.21.4.

Fixed — parent-side relationship.composition reaches the child's FK (migrate-ts; ADR-0047)

ADOPTER-VISIBLE MIGRATION — production delete semantics change. After upgrading, the first meta migrate against a live database emits a one-time migration adding ON DELETE CASCADE (or the relationship's declared/default action) to FKs whose parent-side relationship was previously silently ignored — deleting a parent row then deletes its children instead of failing. This is the documented semantic the metadata always declared, but it was never enforced, so review that migration deliberately; pin @onDelete: "no-action" on any relationship whose DB behavior you want kept. The same applies to a child-side relationship authored with an FQN @objectRef, which the old exact-string correlation silently missed. Give this entry top billing at cut time.

The authoring the docs and the metaobjects-authoring skill teach — declaring the relationship on the PARENT (relationship.composition { @objectRef: "Post", @cardinality: "many" } on Author, with the subtype implying the default action) — contributed nothing to the foreign key: resolveReferentialActions correlated only relationships declared on the FK-owning child, so the documented "composition ⇒ ON DELETE CASCADE default" never fired and deleting a parent with children was a raw FK violation at runtime. The resolver now correlates the reverse relationship on the target entity as a third precedence tier (reference-level attr → child-side relationship → parent-side relationship; each relationship contributing its explicit action, else its subtype default). Tier-2 correlation is now package-aware

... (truncated)

Commits

• fdb8fa4 chore(release): 0.21.6 coordinated (npm/PyPI/NuGet 0.21.6 · Maven 7.21.6)
• b90b693 Merge branch 'worktree-agent-a2ba85024edf22bd0'
• 9787147 test: give all 55 vacuous no-argument toThrow() assertions error identity
• 5d1b993 fix(codegen-ts): a projection's primary key is no longer typed nullable
• 2f2d834 fix(codegen-ts,cli): duplicate imports in generated files under a split ts-po...
• 9e21a23 test(codegen): pin no-duplicate-imports, and record the eq bug as still OPEN
• 65b0181 chore(release): 0.21.5 coordinated (npm/PyPI/NuGet 0.21.5 · Maven 7.21.5)
• 735eb44 perf(codegen): keep Drizzle out of browser bundles — 716 KB → 215 KB
• 235f70e refactor(codegen): the UI tier asks about ENDPOINTS, not about storage
• 633f2f9 fix(hono): TPH routes returned other subtypes' rows; write-through ignored it...
• Additional commits viewable in compare view

Updates @metaobjectsdev/render from 0.20.11 to 0.21.6

Changelog

Sourced from @​metaobjectsdev/render's changelog.

[0.21.6] — npm 0.21.6 · PyPI 0.21.6 · NuGet 0.21.6 · Maven 7.21.6

A coordinated PATCH across all four registries. Two changes alter runtime behaviour on an existing database — read these two before upgrading:

Who this reaches, and when. Neither change is retroactive: nothing happens to a running deployment until you deliberately install 0.21.6. If you depend on ^0.21.x, a routine npm update will pick it up — that is the case to plan for. If you pin exactly ("0.21.5"), you move only on purpose, and nothing below has already happened to you.

1. like is now case-SENSITIVE on Postgres (it was dispatching ILIKE). FR-009 always specified SQL LIKE, and TS's own persistence drivers were already case-sensitive — only one branch of one HTTP parser disagreed, so a query returning extra rows today will return fewer after upgrading. Case-insensitive matching stays available via ?search; an ilike operator remains deliberately unadded (ADR-0049).
2. The first meta migrate after upgrading emits a migration ADDING ON DELETE actions to live foreign keys. A parent-side relationship.composition was silently contributing no referential action; it now contributes its subtype default. This changes production delete semantics — pin @onDelete: "no-action" on the reference to keep current DB behaviour (ADR-0047).

Both are corrections of previously-wrong behaviour rather than contract changes, which is why this is a PATCH — the same call, on the same class of defect, as the Java LIKE fix in 0.21.4.

Fixed — parent-side relationship.composition reaches the child's FK (migrate-ts; ADR-0047)

ADOPTER-VISIBLE MIGRATION — production delete semantics change. After upgrading, the first meta migrate against a live database emits a one-time migration adding ON DELETE CASCADE (or the relationship's declared/default action) to FKs whose parent-side relationship was previously silently ignored — deleting a parent row then deletes its children instead of failing. This is the documented semantic the metadata always declared, but it was never enforced, so review that migration deliberately; pin @onDelete: "no-action" on any relationship whose DB behavior you want kept. The same applies to a child-side relationship authored with an FQN @objectRef, which the old exact-string correlation silently missed. Give this entry top billing at cut time.

The authoring the docs and the metaobjects-authoring skill teach — declaring the relationship on the PARENT (relationship.composition { @objectRef: "Post", @cardinality: "many" } on Author, with the subtype implying the default action) — contributed nothing to the foreign key: resolveReferentialActions correlated only relationships declared on the FK-owning child, so the documented "composition ⇒ ON DELETE CASCADE default" never fired and deleting a parent with children was a raw FK violation at runtime. The resolver now correlates the reverse relationship on the target entity as a third precedence tier (reference-level attr → child-side relationship → parent-side relationship; each relationship contributing its explicit action, else its subtype default). Tier-2 correlation is now package-aware

... (truncated)

Commits

• fdb8fa4 chore(release): 0.21.6 coordinated (npm/PyPI/NuGet 0.21.6 · Maven 7.21.6)
• 65b0181 chore(release): 0.21.5 coordinated (npm/PyPI/NuGet 0.21.5 · Maven 7.21.5)
• 3948bb9 chore(release): 0.21.4 coordinated (npm/PyPI/NuGet 0.21.4 · Maven 7.21.4)
• 0d1a74a chore(release): @​metaobjectsdev TypeScript packages 0.21.3
• 4bdde5b chore(release): @​metaobjectsdev TypeScript packages 0.21.2
• 35b0250 chore(release): @​metaobjectsdev TypeScript packages 0.21.1
• 5c0bcd5 chore(release): 0.21.0 coordinated MINOR (npm/PyPI/NuGet 0.21.0 · Maven 7.21.0)
• a4c4d0b chore(release): 0.20.16 coordinated (npm/PyPI/NuGet 0.20.16 · Maven 7.20.16)
• 0777ccd chore(release): 0.20.15 coordinated (npm/PyPI/NuGet 0.20.15 · Maven 7.20.15)
• 0972ecf chore(release): 0.20.14 coordinated (npm/PyPI/NuGet 0.20.14 · Maven 7.20.14)
• Additional commits viewable in compare view

Updates @metaobjectsdev/runtime-ts from 0.20.11 to 0.21.6

Changelog

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

[0.21.6] — npm 0.21.6 · PyPI 0.21.6 · NuGet 0.21.6 · Maven 7.21.6

A coordinated PATCH across all four registries. Two changes alter runtime behaviour on an existing database — read these two before upgrading:

Who this reaches, and when. Neither change is retroactive: nothing happens to a running deployment until you deliberately install 0.21.6. If you depend on ^0.21.x, a routine npm update will pick it up — that is the case to plan for. If you pin exactly ("0.21.5"), you move only on purpose, and nothing below has already happened to you.

1. like is now case-SENSITIVE on Postgres (it was dispatching ILIKE). FR-009 always specified SQL LIKE, and TS's own persistence drivers were already case-sensitive — only one branch of one HTTP parser disagreed, so a query returning extra rows today will return fewer after upgrading. Case-insensitive matching stays available via ?search; an ilike operator remains deliberately unadded (ADR-0049).
2. The first meta migrate after upgrading emits a migration ADDING ON DELETE actions to live foreign keys. A parent-side relationship.composition was silently contributing no referential action; it now contributes its subtype default. This changes production delete semantics — pin @onDelete: "no-action" on the reference to keep current DB behaviour (ADR-0047).

Both are corrections of previously-wrong behaviour rather than contract changes, which is why this is a PATCH — the same call, on the same class of defect, as the Java LIKE fix in 0.21.4.

Fixed — parent-side relationship.composition reaches the child's FK (migrate-ts; ADR-0047)

ADOPTER-VISIBLE MIGRATION — production delete semantics change. After upgrading, the first meta migrate against a live database emits a one-time migration adding ON DELETE CASCADE (or the relationship's declared/default action) to FKs whose parent-side relationship was previously silently ignored — deleting a parent row then deletes its children instead of failing. This is the documented semantic the metadata always declared, but it was never enforced, so review that migration deliberately; pin @onDelete: "no-action" on any relationship whose DB behavior you want kept. The same applies to a child-side relationship authored with an FQN @objectRef, which the old exact-string correlation silently missed. Give this entry top billing at cut time.

The authoring the docs and the metaobjects-authoring skill teach — declaring the relationship on the PARENT (relationship.composition { @objectRef: "Post", @cardinality: "many" } on Author, with the subtype implying the default action) — contributed nothing to the foreign key: resolveReferentialActions correlated only relationships declared on the FK-owning child, so the documented "composition ⇒ ON DELETE CASCADE default" never fired and deleting a parent with children was a raw FK violation at runtime. The resolver now correlates the reverse relationship on the target entity as a third precedence tier (reference-level attr → child-side relationship → parent-side relationship; each relationship contributing its explicit action, else its subtype default). Tier-2 correlation is now package-aware

... (truncated)

Commits

• fdb8fa4 chore(release): 0.21.6 coordinated (npm/PyPI/NuGet 0.21.6 · Maven 7.21.6)
• 976cd59 Merge branch 'worktree-agent-ade1891cf8f8322b3'
• 9787147 test: give all 55 vacuous no-argument toThrow() assertions error identity
• fe8459a fix!: like is case-sensitive SQL LIKE in every port; de-blind the corpora (...
• 65b0181 chore(release): 0.21.5 coordinated (npm/PyPI/NuGet 0.21.5 · Maven 7.21.5)
• 742bc7c fix(runtime-ts): db.all(sql.raw(...)) 500s on Postgres in BOTH read-only mounts
• 094b346 fix(runtime-ts): type the matrix's write-verb sender to satisfy Fastify's inject
• 651fb59 test(runtime-ts): the PG matrix was GET-only — add the write verbs
• 633f2f9 fix(hono): TPH routes returned other subtypes' rows; write-through ignored it...
• 2c690e0 fix: bound every peer range, and stop emitting artifacts for sourceless objects
• Additional commits viewable in compare view

Updates @metaobjectsdev/sdk from 0.20.11 to 0.21.6

Changelog

Sourced from @​metaobjectsdev/sdk's changelog.

[0.21.6] — npm 0.21.6 · PyPI 0.21.6 · NuGet 0.21.6 · Maven 7.21.6

A coordinated PATCH across all four registries. Two changes alter runtime behaviour on an existing database — read these two before upgrading:

Who this reaches, and when. Neither change is retroactive: nothing happens to a running deployment until you deliberately install 0.21.6. If you depend on ^0.21.x, a routine npm update will pick it up — that is the case to plan for. If you pin exactly ("0.21.5"), you move only on purpose, and nothing below has already happened to you.

1. like is now case-SENSITIVE on Postgres (it was dispatching ILIKE). FR-009 always specified SQL LIKE, and TS's own persistence drivers were already case-sensitive — only one branch of one HTTP parser disagreed, so a query returning extra rows today will return fewer after upgrading. Case-insensitive matching stays available via ?search; an ilike operator remains deliberately unadded (ADR-0049).
2. The first meta migrate after upgrading emits a migration ADDING ON DELETE actions to live foreign keys. A parent-side relationship.composition was silently contributing no referential action; it now contributes its subtype default. This changes production delete semantics — pin @onDelete: "no-action" on the reference to keep current DB behaviour (ADR-0047).

Both are corrections of previously-wrong behaviour rather than contract changes, which is why this is a PATCH — the same call, on the same class of defect, as the Java LIKE fix in 0.21.4.

Fixed — parent-side relationship.composition reaches the child's FK (migrate-ts; ADR-0047)

ADOPTER-VISIBLE MIGRATION — production delete semantics change. After upgrading, the first meta migrate against a live database emits a one-time migration adding ON DELETE CASCADE (or the relationship's declared/default action) to FKs whose parent-side relationship was previously silently ignored — deleting a parent row then deletes its children instead of failing. This is the documented semantic the metadata always declared, but it was never enforced, so review that migration deliberately; pin @onDelete: "no-action" on any relationship whose DB behavior you want kept. The same applies to a child-side relationship authored with an FQN @objectRef, which the old exact-string correlation silently missed. Give this entry top billing at cut time.

The authoring the docs and the metaobjects-authoring skill teach — declaring the relationship on the PARENT (relationship.composition { @objectRef: "Post", @cardinality: "many" } on Author, with the subtype implying the default action) — contributed nothing to the foreign key: resolveReferentialActions correlated only relationships declared on the FK-owning child, so the documented "composition ⇒ ON DELETE CASCADE default" never fired and deleting a parent with children was a raw FK violation at runtime. The resolver now correlates the reverse relationship on the target entity as a third precedence tier (reference-level attr → child-side relationship → parent-side relationship; each relationship contributing its explicit action, else its subtype default). Tier-2 correlation is now package-aware

... (truncated)

Commits

• fdb8fa4 chore(release): 0.21.6 coordinated (npm/PyPI/NuGet 0.21.6 · Maven 7.21.6)
• 9787147 test: give all 55 vacuous no-argument toThrow() assertions error identity
• 3b9b111 docs: stop showing a like example that generated TS routes always 400
• 65b0181 chore(release): 0.21.5 coordinated (npm/PyPI/NuGet 0.21.5 · Maven 7.21.5)
• 3948bb9 chore(release): 0.21.4 coordinated (npm/PyPI/NuGet 0.21.4 · Maven 7.21.4)
• 0d1a74a chore(release): @​metaobjectsdev TypeScript packages 0.21.3
• 4bdde5b chore(release): @​metaobjectsdev TypeScript packages 0.21.2
• 18e1e6e fix(sdk,cli): sync AllowTokenEnum to the full 11 --allow tokens; pin the lists
• 35b0250 chore(release): @​metaobjectsdev TypeScript packages 0.21.1
• 7138e58 fix(agent-context): restore compilable JSON-layer FQNs, fix docs self-refutat...
• Additional commits viewable in compare view

Updates @metaobjectsdev/metadata from 0.20.11 to 0.21.6

Changelog

Sourced from @​metaobjectsdev/metadata's changelog.

[0.21.6] — npm 0.21.6 · PyPI 0.21.6 · NuGet 0.21.6 · Maven 7.21.6

A coordinated PATCH across all four registries. Two changes alter runtime behaviour on an existing database — read these two before upgrading:

Who this reaches, and when. Neither change is retroactive: nothing happens to a running deployment until you deliberately install 0.21.6. If you depend on ^0.21.x, a routine npm update will pick it up — that is the case to plan for. If you pin exactly ("0.21.5"), you move only on purpose, and nothing below has already happened to you.

1. like is now case-SENSITIVE on Postgres (it was dispatching ILIKE). FR-009 always specified SQL LIKE, and TS's own persistence drivers were already case-sensitive — only one branch of one HTTP parser disagreed, so a query returning extra rows today will return fewer after upgrading. Case-insensitive matching stays available via ?search; an ilike operator remains deliberately unadded (ADR-0049).
2. The first meta migrate after upgrading emits a migration ADDING ON DELETE actions to live foreign keys. A parent-side relationship.composition was silently contributing no referential action; it now contributes its subtype default. This changes production delete semantics — pin @onDelete: "no-action" on the reference to keep current DB behaviour (ADR-0047).

Both are corrections of previously-wrong behaviour rather than contract changes, which is why this is a PATCH — the same call, on the same class of defect, as the Java LIKE fix in 0.21.4.

Fixed — parent-side relationship.composition reaches the child's FK (migrate-ts; ADR-0047)

ADOPTER-VISIBLE MIGRATION — production delete semantics change. After upgrading, the first meta migrate against a live database emits a one-time migration adding ON DELETE CASCADE (or the relationship's declared/default action) to FKs whose parent-side relationship was previously silently ignored — deleting a parent row then deletes its children instead of failing. This is the documented semantic the metadata always declared, but it was never enforced, so review that migration deliberately; pin @onDelete: "no-action" on any relationship whose DB behavior you want kept. The same applies to a child-side relationship authored with an FQN @objectRef, which the old exact-string correlation silently missed. Give this entry top billing at cut time.

The authoring the docs and the metaobjects-authoring skill teach — declaring the relationship on the PARENT (relationship.composition { @objectRef: "Post", @cardinality: "many" } on Author, with the subtype implying the default action) — contributed nothing to the foreign key: resolveReferentialActions correlated only relationships declared on the FK-owning child, so the documented "composition ⇒ ON DELETE CASCADE default" never fired and deleting a parent with children was a raw FK violation at runtime. The resolver now correlates the reverse relationship on the target entity as a third precedence tier (reference-level attr → child-side relationship → parent-side relationship; each relationship contributing its explicit action, else its subtype default). Tier-2 correlation is now package-aware

... (truncated)

Commits

• fdb8fa4 chore(release): 0.21.6 coordinated (npm/PyPI/NuGet 0.21.6 · Maven 7.21.6)
• dbd7b86 Merge branch 'worktree-agent-a7158261af3b52cc6'
• 9787147 test: give all 55 vacuous no-argument toThrow() assertions error identity
• 123c691 fix(migrate-ts,metamodel): parent-side composition reaches the FK; register i...
• 65b0181 chore(release): 0.21.5 coordinated (npm/PyPI/NuGet 0.21.5 · Maven 7.21.5)
• 3948bb9 chore(release): 0.21.4 coordinated (npm/PyPI/NuGet 0.21.4 · Maven 7.21.4)
• b145e94 fix: the two adopter blockers — sqlite apply, and browser bundling (#287)
• 0d1a74a chore(release): @​metaobjectsdev TypeScript packages 0.21.3
• 4bdde5b chore(release): @​metaobjectsdev TypeScript packages 0.21.2
• 35b0250 chore(release): @​metaobjectsdev TypeScript packages 0.21.1
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions