From ed1d16defd2c4eba480ed278a22e4820d9e508d5 Mon Sep 17 00:00:00 2001 From: Anthony Smith Date: Mon, 20 Jul 2026 14:43:36 -0400 Subject: [PATCH 1/5] docs: clarify accelerator error boundaries --- .../0001-observable-key-accelerator-errors.md | 61 +++++++++++++++---- 1 file changed, 48 insertions(+), 13 deletions(-) diff --git a/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md b/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md index a013219f3b8e..4a3516658c13 100644 --- a/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md +++ b/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md @@ -18,24 +18,51 @@ builder API. ## Decision -Keep the existing `build() -> Item` signatures. Address the discarded-result -behavior consistently across all three builders in a dedicated Muda change by -constructing each item with its `KeyAccelerator` already stored, using -crate-private construction helpers where needed. Platform validation or -installation failures will then be returned by the existing fallible menu -attachment operations, such as `Menu::append` and `Menu::insert`. +Keep the existing `build() -> Item` signatures. `build()` must not call +`set_key_accelerator()`. Instead, it constructs each item with its +`KeyAccelerator` stored, using crate-private construction helpers where needed. +Construction neither converts the accelerator for a native backend nor installs +it. The backend validates and applies it when materializing the item for a menu, +once per native representation; it is not first applied during `build()` and +then applied again during attachment. + +The error boundary is the first fallible operation that materializes the native +representation. On Windows and macOS this is normally `Menu::append`, +`Menu::insert`, or the corresponding `Submenu` operation. On GTK, adding an item +before a menu instance exists only records the child, so validation or +installation may instead occur during `init_for_gtk_window`; adding to an +already initialized menu performs it during the add operation. + +Add `try_build() -> crate::Result` consistently to all three builders as +an opt-in early check. It performs side-effect-free validation that the +configured `KeyAccelerator` is representable by the target backend, then uses +the same stored construction path as `build()`. It is a validation pass, not a +trial installation into a temporary native menu, so menu-context failures can +still occur later. + +The builder's `id: Option` represents only whether the caller supplied +an explicit ID. Construction always assigns a concrete `MenuId` when none was +provided. This decision introduces no optional item ID; any future diagnostic +that identifies a constructed item should use `MenuId`, not `Option`. Do not panic, silently remove the configured accelerator, or change only the -icon-item builder. If a platform must validate an accelerator before menu -attachment, introduce an additive `try_build()` API for all three builders and -reserve any change to the existing `build()` return type for a major release. +icon-item builder. Reserve any change to the existing `build()` return type for +a major release. Attachment must validate before mutating parent state, or roll +back that state if native materialization fails. ## Consequences - Existing callers keep their current source-compatible builder API. - A configured `KeyAccelerator` is retained instead of being silently dropped. +- `build()` performs no native accelerator work; `try_build()` provides an + additive early representability check for callers that require one. - Platform-specific failures surface through an existing `Result` boundary, - although potentially later when the item is attached to a menu. + potentially later when the item is attached or the menu is initialized. +- An item that is built but never attached or materialized never surfaces a + deferred backend error. This is accepted because it never acquires a native + accelerator; callers that need eager validation can use `try_build()`. +- `try_build()` cannot guarantee that later menu-context installation succeeds. +- Every successfully built item has a concrete `MenuId`. - The implementation and tests must cover all three builders together. ## Rejected alternatives @@ -46,10 +73,18 @@ reserve any change to the existing `build()` return type for a major release. platform error into a process failure. - Continuing to discard `set_key_accelerator()` errors: silently loses the caller's configured behavior. +- Calling `set_key_accelerator()` during `build()` and applying it again during + attachment: duplicates backend work and retains the swallowed-error problem. +- Having `try_build()` install into a temporary native menu: introduces native + side effects and still cannot prove that installation in the real menu will + succeed. ## Validation The follow-up implementation must verify that each builder retains its key -accelerator and that unsupported platform accelerators are reported by a -fallible operation. It must also compile existing `build()` call sites without -changes. +accelerator without invoking backend installation during `build()`, and that it +is applied once per native representation during attachment or initialization. +`try_build()` must accept and reject representative supported and unsupported +keys without creating a native menu. A failed materialization must not leave the +item partially attached. Tests must also cover automatic `MenuId` assignment +and compile existing `build()` call sites without changes. From 7bf2c91b20a876d4c0fe57fae2481ae7cf6f7702 Mon Sep 17 00:00:00 2001 From: Anthony Smith Date: Mon, 20 Jul 2026 14:56:02 -0400 Subject: [PATCH 2/5] docs: define accelerator failure payloads --- .../0001-observable-key-accelerator-errors.md | 74 +++++++++++++++++-- 1 file changed, 68 insertions(+), 6 deletions(-) diff --git a/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md b/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md index 4a3516658c13..f9e212ee4e8a 100644 --- a/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md +++ b/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md @@ -16,6 +16,11 @@ builders inconsistent. Changing all three methods would make platform failures observable immediately, but it would also be a breaking change to the public builder API. +Deferring backend validation can also make it harder to identify the failing +child when an operation materializes several items. The existing transparent +accelerator error does not preserve that item identity. This ADR therefore +includes both per-item and aggregate application errors. + ## Decision Keep the existing `build() -> Item` signatures. `build()` must not call @@ -33,17 +38,59 @@ before a menu instance exists only records the child, so validation or installation may instead occur during `init_for_gtk_window`; adding to an already initialized menu performs it during the add operation. +Backend representability or application failures must be reported as: + +```rust +Error::AcceleratorApplicationFailed { + item_id: MenuId, + accelerator: KeyAccelerator, +} +``` + +The variant carries the exact attempted item and accelerator. Syntax and +conversion failures raised while configuring a builder remain +`AcceleratorParseError`; failures showing that an already parsed accelerator +cannot be applied by the target backend use the new variant. + +Batch operations use a typed payload and aggregate variant: + +```rust +pub struct AcceleratorApplicationFailure { + pub item_id: MenuId, + pub accelerator: KeyAccelerator, +} + +Error::AcceleratorBatchApplicationFailed { + failures: Vec, +} +``` + +`Menu::append_items`, `Menu::insert_items`, `Menu::prepend_items`, their +`Submenu` equivalents, and GTK initialization prevalidate every item they would +materialize. If any validation fails, they return a non-empty `failures` list in +input order, using depth-first child order for a recorded menu tree, and perform +no materialization. A batch API uses the aggregate variant even when only one +item fails; single-item operations and `try_build()` use +`AcceleratorApplicationFailed`. + +When GTK initialization materializes multiple recorded children, it must +prevalidate every configured accelerator before materializing any child. It +collects every failure in deterministic traversal order and leaves the batch +unmaterialized when the collection is non-empty. + Add `try_build() -> crate::Result` consistently to all three builders as an opt-in early check. It performs side-effect-free validation that the configured `KeyAccelerator` is representable by the target backend, then uses the same stored construction path as `build()`. It is a validation pass, not a trial installation into a temporary native menu, so menu-context failures can -still occur later. +still occur later. It must resolve the item's concrete ID before validation so +an `AcceleratorApplicationFailed` error identifies the attempted item. The builder's `id: Option` represents only whether the caller supplied an explicit ID. Construction always assigns a concrete `MenuId` when none was provided. This decision introduces no optional item ID; any future diagnostic -that identifies a constructed item should use `MenuId`, not `Option`. +that identifies a constructed item, including `AcceleratorApplicationFailed`, +uses `MenuId`, not `Option`. Do not panic, silently remove the configured accelerator, or change only the icon-item builder. Reserve any change to the existing `build()` return type for @@ -62,7 +109,13 @@ back that state if native materialization fails. deferred backend error. This is accepted because it never acquires a native accelerator; callers that need eager validation can use `try_build()`. - `try_build()` cannot guarantee that later menu-context installation succeeds. -- Every successfully built item has a concrete `MenuId`. +- Representability and application failures identify the exact `MenuId` and + `KeyAccelerator`. The additive variant is compatible with the existing + non-exhaustive `Error` enum. +- Batch operations report every accelerator failure through a typed, ordered + aggregate payload instead of forcing callers to fix one item per attempt. +- GTK accelerator validation during initialization is collecting and batch-atomic. +- Every built item has a concrete `MenuId`. - The implementation and tests must cover all three builders together. ## Rejected alternatives @@ -73,6 +126,10 @@ back that state if native materialization fails. platform error into a process failure. - Continuing to discard `set_key_accelerator()` errors: silently loses the caller's configured behavior. +- Returning only the underlying `AcceleratorParseError` from attachment: + preserves the cause category but loses the identity of the failing item. +- Returning only the first accelerator error from a batch: hides other invalid + items and requires repeated materialization attempts to discover them. - Calling `set_key_accelerator()` during `build()` and applying it again during attachment: duplicates backend work and retains the swallowed-error problem. - Having `try_build()` install into a temporary native menu: introduces native @@ -85,6 +142,11 @@ The follow-up implementation must verify that each builder retains its key accelerator without invoking backend installation during `build()`, and that it is applied once per native representation during attachment or initialization. `try_build()` must accept and reject representative supported and unsupported -keys without creating a native menu. A failed materialization must not leave the -item partially attached. Tests must also cover automatic `MenuId` assignment -and compile existing `build()` call sites without changes. +keys without creating a native menu, and its error must contain the resolved +`MenuId` and configured `KeyAccelerator`. A failed materialization must not leave +the item partially attached. A GTK initialization test with an invalid +accelerator among multiple recorded children must verify that none of the batch +is materialized and that `AcceleratorBatchApplicationFailed` contains every +invalid child in deterministic order. Batch APIs must also be tested with one +failure to preserve their aggregate return shape. Tests must cover automatic +`MenuId` assignment and compile existing `build()` call sites without changes. From c0d2740585442b6255625fa4607729e3c68a73fe Mon Sep 17 00:00:00 2001 From: Anthony Smith Date: Mon, 20 Jul 2026 15:06:11 -0400 Subject: [PATCH 3/5] docs: define GTK accelerator recovery --- .../0001-observable-key-accelerator-errors.md | 28 +++++++++++++------ 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md b/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md index f9e212ee4e8a..efa45c2e124b 100644 --- a/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md +++ b/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md @@ -68,15 +68,18 @@ Error::AcceleratorBatchApplicationFailed { `Menu::append_items`, `Menu::insert_items`, `Menu::prepend_items`, their `Submenu` equivalents, and GTK initialization prevalidate every item they would materialize. If any validation fails, they return a non-empty `failures` list in -input order, using depth-first child order for a recorded menu tree, and perform -no materialization. A batch API uses the aggregate variant even when only one -item fails; single-item operations and `try_build()` use +input order (for a recorded menu tree, input order is depth-first child order) +and perform no materialization. A batch API uses the aggregate variant even +when only one item fails; single-item operations and `try_build()` use `AcceleratorApplicationFailed`. When GTK initialization materializes multiple recorded children, it must prevalidate every configured accelerator before materializing any child. It collects every failure in deterministic traversal order and leaves the batch -unmaterialized when the collection is non-empty. +unmaterialized when the collection is non-empty. Validation occurs before the +window/menu instance is registered or native state is mutated. On failure, the +recorded child tree remains in place and the window remains uninitialized, so +the caller can correct the identified items and retry `init_for_gtk_window`. Add `try_build() -> crate::Result` consistently to all three builders as an opt-in early check. It performs side-effect-free validation that the @@ -94,8 +97,8 @@ uses `MenuId`, not `Option`. Do not panic, silently remove the configured accelerator, or change only the icon-item builder. Reserve any change to the existing `build()` return type for -a major release. Attachment must validate before mutating parent state, or roll -back that state if native materialization fails. +a major release. Attachment and initialization must validate before mutating +parent state, or roll back that state if native materialization fails. ## Consequences @@ -114,7 +117,8 @@ back that state if native materialization fails. non-exhaustive `Error` enum. - Batch operations report every accelerator failure through a typed, ordered aggregate payload instead of forcing callers to fix one item per attempt. -- GTK accelerator validation during initialization is collecting and batch-atomic. +- GTK accelerator validation during initialization collects every failure and + is batch-atomic. Failed validation preserves the recorded children for retry. - Every built item has a concrete `MenuId`. - The implementation and tests must cover all three builders together. @@ -130,6 +134,8 @@ back that state if native materialization fails. preserves the cause category but loses the identity of the failing item. - Returning only the first accelerator error from a batch: hides other invalid items and requires repeated materialization attempts to discover them. +- Materializing valid items while skipping invalid ones: leaves callers with a + partial native menu and makes correction and retry state-dependent. - Calling `set_key_accelerator()` during `build()` and applying it again during attachment: duplicates backend work and retains the swallowed-error problem. - Having `try_build()` install into a temporary native menu: introduces native @@ -148,5 +154,9 @@ the item partially attached. A GTK initialization test with an invalid accelerator among multiple recorded children must verify that none of the batch is materialized and that `AcceleratorBatchApplicationFailed` contains every invalid child in deterministic order. Batch APIs must also be tested with one -failure to preserve their aggregate return shape. Tests must cover automatic -`MenuId` assignment and compile existing `build()` call sites without changes. +failure to preserve their aggregate return shape. After a failed GTK +initialization, tests must verify that the recorded children remain unchanged, +the window is not marked initialized, and correcting the invalid accelerator +allows a retry to materialize the full batch exactly once. Tests must cover +automatic `MenuId` assignment and compile existing `build()` call sites without +changes. From 520deb60910e08fa3ec22725bec23a7cc869edbb Mon Sep 17 00:00:00 2001 From: Anthony Smith Date: Thu, 23 Jul 2026 08:48:37 -0400 Subject: [PATCH 4/5] docs(muda): clarify accelerator failure contract --- .../0001-observable-key-accelerator-errors.md | 37 +++++++++++++------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md b/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md index efa45c2e124b..bc5ca4decae3 100644 --- a/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md +++ b/ports/muda/docs/adr/0001-observable-key-accelerator-errors.md @@ -73,21 +73,32 @@ and perform no materialization. A batch API uses the aggregate variant even when only one item fails; single-item operations and `try_build()` use `AcceleratorApplicationFailed`. +Only accelerator representability or application failures are collected in +`AcceleratorBatchApplicationFailed`. Structural and lifecycle errors that are +not representable by `AcceleratorApplicationFailure`, including +`NotAChildOfThisMenu` and `AlreadyInitialized`, remain direct `Error` returns +from `Menu`, `Submenu`, and GTK initialization operations. Accelerator +prevalidation does not reclassify or aggregate those unrelated errors. + When GTK initialization materializes multiple recorded children, it must prevalidate every configured accelerator before materializing any child. It collects every failure in deterministic traversal order and leaves the batch unmaterialized when the collection is non-empty. Validation occurs before the window/menu instance is registered or native state is mutated. On failure, the -recorded child tree remains in place and the window remains uninitialized, so -the caller can correct the identified items and retry `init_for_gtk_window`. +recorded child tree structure and ordering remain in place and the window +remains uninitialized. Each child's accelerator configuration remains editable, +so the caller can correct the identified items and retry +`init_for_gtk_window`. Add `try_build() -> crate::Result` consistently to all three builders as -an opt-in early check. It performs side-effect-free validation that the -configured `KeyAccelerator` is representable by the target backend, then uses -the same stored construction path as `build()`. It is a validation pass, not a -trial installation into a temporary native menu, so menu-context failures can -still occur later. It must resolve the item's concrete ID before validation so -an `AcceleratorApplicationFailed` error identifies the attempted item. +an opt-in early check. It performs validation without creating or mutating +native backend state, then uses the same stored construction path as `build()`. +It is a validation pass, not a trial installation into a temporary native menu, +so menu-context failures can still occur later. It must resolve the item's +concrete ID before validation so an `AcceleratorApplicationFailed` error +identifies the attempted item. When the caller did not provide an ID, resolving +that ID consumes the next value from the monotonic ID counter even if validation +rejects the item; gaps from rejected `try_build()` attempts are expected. The builder's `id: Option` represents only whether the caller supplied an explicit ID. Construction always assigns a concrete `MenuId` when none was @@ -156,7 +167,9 @@ is materialized and that `AcceleratorBatchApplicationFailed` contains every invalid child in deterministic order. Batch APIs must also be tested with one failure to preserve their aggregate return shape. After a failed GTK initialization, tests must verify that the recorded children remain unchanged, -the window is not marked initialized, and correcting the invalid accelerator -allows a retry to materialize the full batch exactly once. Tests must cover -automatic `MenuId` assignment and compile existing `build()` call sites without -changes. +including their tree structure and ordering, while the window is not marked +initialized. They must also verify that an invalid child's accelerator remains +editable and that correcting it allows a retry to materialize the full batch +exactly once. Tests must cover automatic `MenuId` assignment, including +monotonic ID consumption by rejected `try_build()` attempts, and compile +existing `build()` call sites without changes. From dfb6ff75496b98068cdbf2eac430f7fe3bfc23be Mon Sep 17 00:00:00 2001 From: Anthony Smith Date: Thu, 23 Jul 2026 09:05:06 -0400 Subject: [PATCH 5/5] chore(deps): remediate JavaScript audit findings --- pnpm-lock.yaml | 296 ++++++++++++++++++++++++-------------------- pnpm-workspace.yaml | 3 + 2 files changed, 166 insertions(+), 133 deletions(-) diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml index a030abe21393..a1ffb3ca70c4 100644 --- a/pnpm-lock.yaml +++ b/pnpm-lock.yaml @@ -5,7 +5,10 @@ settings: excludeLinksFromLockfile: false overrides: + brace-expansion@>=3.0.0 <5.0.7: 5.0.7 esbuild@>=0.27.3 <0.28.1: '>=0.28.1' + js-yaml@>=4.0.0 <4.3.0: 4.3.0 + sharp@<0.35.0: 0.35.3 ws@>=8.0.0 <8.20.1: '>=8.20.1' importers: @@ -420,152 +423,161 @@ packages: resolution: {integrity: sha512-Td76q7j57o/tLVdgS746cYARfSyxk8iEfRxewL9h4OMzYhbW4TAcppl0mT4eyqXddh6L/jwoM75mo7ixa/pCeQ==} engines: {node: '>=18'} - '@img/sharp-darwin-arm64@0.34.5': - resolution: {integrity: sha512-imtQ3WMJXbMY4fxb/Ndp6HBTNVtWCUI0WdobyheGf5+ad6xX8VIDO8u2xE4qc/fr08CKG/7dDseFtn6M6g/r3w==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-darwin-arm64@0.35.3': + resolution: {integrity: sha512-RMnFX7YQsMoh7lWfcM4NEHHymBX/rLuKNPVM84XE9ONPcaSCDgE7CHIHpSgPcO2xcRthgBy1HfNO319mwhIAkg==} + engines: {node: '>=20.9.0'} cpu: [arm64] os: [darwin] - '@img/sharp-darwin-x64@0.34.5': - resolution: {integrity: sha512-YNEFAF/4KQ/PeW0N+r+aVVsoIY0/qxxikF2SWdp+NRkmMB7y9LBZAVqQ4yhGCm/H3H270OSykqmQMKLBhBJDEw==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-darwin-x64@0.35.3': + resolution: {integrity: sha512-Xo+5uFBtLN0BKqieTxiFzFPQAUlBbbH5iBKyRX/z1JrbnYsHTfKJnUfL8+p2TPXr1pXqao4eeL4Rl144uDpK9w==} + engines: {node: '>=20.9.0'} cpu: [x64] os: [darwin] - '@img/sharp-libvips-darwin-arm64@1.2.4': - resolution: {integrity: sha512-zqjjo7RatFfFoP0MkQ51jfuFZBnVE2pRiaydKJ1G/rHZvnsrHAOcQALIi9sA5co5xenQdTugCvtb1cuf78Vf4g==} + '@img/sharp-freebsd-wasm32@0.35.3': + resolution: {integrity: sha512-lUxcqWIj2wMQ9BrwNjngcr1gWUr5xgaGThBRqPPalIC2n67Cqj1uPh8NnA/ZhAg8hUbKl+kVHKwgUIwe6ZYPrg==} + engines: {node: '>=20.9.0'} + os: [freebsd] + + '@img/sharp-libvips-darwin-arm64@1.3.2': + resolution: {integrity: sha512-9J6ypZFpQBj4YnePGoq/S38w6nz+vqg5WZLrLGY4YuSemdMq47GMLBPO42MzwdGwpg/agZ7xzZcFHa48xlywfg==} cpu: [arm64] os: [darwin] - '@img/sharp-libvips-darwin-x64@1.2.4': - resolution: {integrity: sha512-1IOd5xfVhlGwX+zXv2N93k0yMONvUlANylbJw1eTah8K/Jtpi15KC+WSiaX/nBmbm2HxRM1gZ0nSdjSsrZbGKg==} + '@img/sharp-libvips-darwin-x64@1.3.2': + resolution: {integrity: sha512-m2pW1n6cns9VaubNwsZ+c3CRYjxNQWgJ5gPlnL1nbBcpkBvFm6SCFN5o0psFHI8w9n11NKhFkeEDns98tiqbEw==} cpu: [x64] os: [darwin] - '@img/sharp-libvips-linux-arm64@1.2.4': - resolution: {integrity: sha512-excjX8DfsIcJ10x1Kzr4RcWe1edC9PquDRRPx3YVCvQv+U5p7Yin2s32ftzikXojb1PIFc/9Mt28/y+iRklkrw==} + '@img/sharp-libvips-linux-arm64@1.3.2': + resolution: {integrity: sha512-dqVSFynCox4C/J8kT16V7SIFAns0IjgLwkvYT7p8LQVmJ5OS5b6tI9IGflxTeuBS//zXeFIUbwt5dwxyZ17cnA==} cpu: [arm64] os: [linux] libc: [glibc] - '@img/sharp-libvips-linux-arm@1.2.4': - resolution: {integrity: sha512-bFI7xcKFELdiNCVov8e44Ia4u2byA+l3XtsAj+Q8tfCwO6BQ8iDojYdvoPMqsKDkuoOo+X6HZA0s0q11ANMQ8A==} + '@img/sharp-libvips-linux-arm@1.3.2': + resolution: {integrity: sha512-1eMLzy92I4J6rmi4mAT8yC3HxOtniyGELlzGbNMLLeqe052ahFQ0h6LFq+lh5DsDIdYViIDst08abvSbcEdLXQ==} cpu: [arm] os: [linux] libc: [glibc] - '@img/sharp-libvips-linux-ppc64@1.2.4': - resolution: {integrity: sha512-FMuvGijLDYG6lW+b/UvyilUWu5Ayu+3r2d1S8notiGCIyYU/76eig1UfMmkZ7vwgOrzKzlQbFSuQfgm7GYUPpA==} + '@img/sharp-libvips-linux-ppc64@1.3.2': + resolution: {integrity: sha512-3z0NHDxD6n5I9gc05U1eW1AyRm+Gznzq3naMrthPNqE6oYykcogW0l/jfpJdjYnuNl8R7yI9pNbE1XiUeyq0Aw==} cpu: [ppc64] os: [linux] libc: [glibc] - '@img/sharp-libvips-linux-riscv64@1.2.4': - resolution: {integrity: sha512-oVDbcR4zUC0ce82teubSm+x6ETixtKZBh/qbREIOcI3cULzDyb18Sr/Wcyx7NRQeQzOiHTNbZFF1UwPS2scyGA==} + '@img/sharp-libvips-linux-riscv64@1.3.2': + resolution: {integrity: sha512-bsb4rI+NldGOsXuej2r8OdSS8+zXDVaCWxyWrcv6kneTOlgAHtZABRzBBCwdsPiD90J4myNJuHpg6kA20ImW/w==} cpu: [riscv64] os: [linux] libc: [glibc] - '@img/sharp-libvips-linux-s390x@1.2.4': - resolution: {integrity: sha512-qmp9VrzgPgMoGZyPvrQHqk02uyjA0/QrTO26Tqk6l4ZV0MPWIW6LTkqOIov+J1yEu7MbFQaDpwdwJKhbJvuRxQ==} + '@img/sharp-libvips-linux-s390x@1.3.2': + resolution: {integrity: sha512-/ABshyj8gCpyIrNXnHn4LorDJ0HHm1VhXPBlxZ8zAtfVPAaSafXPGn+sUSIRiwaSBy0mmFjSjiXI5mkcwdChKQ==} cpu: [s390x] os: [linux] libc: [glibc] - '@img/sharp-libvips-linux-x64@1.2.4': - resolution: {integrity: sha512-tJxiiLsmHc9Ax1bz3oaOYBURTXGIRDODBqhveVHonrHJ9/+k89qbLl0bcJns+e4t4rvaNBxaEZsFtSfAdquPrw==} + '@img/sharp-libvips-linux-x64@1.3.2': + resolution: {integrity: sha512-ITPEtgffGJ0S6G9dRyw/366tJQqFRcHWPHhC+Stpg3Z8AEMrDrTr2lhdz4f/Y/HMbRh//7Z5mBzEpVdi62Oc3w==} cpu: [x64] os: [linux] libc: [glibc] - '@img/sharp-libvips-linuxmusl-arm64@1.2.4': - resolution: {integrity: sha512-FVQHuwx1IIuNow9QAbYUzJ+En8KcVm9Lk5+uGUQJHaZmMECZmOlix9HnH7n1TRkXMS0pGxIJokIVB9SuqZGGXw==} + '@img/sharp-libvips-linuxmusl-arm64@1.3.2': + resolution: {integrity: sha512-zE9EdiUzUmg5mDT5a1rk5fYJ6GWPloTwWBYDS14naqHsL+EaMpDj1AWnpLgh3u0YCORv2Tt50wrcrpYqkP97Kw==} cpu: [arm64] os: [linux] libc: [musl] - '@img/sharp-libvips-linuxmusl-x64@1.2.4': - resolution: {integrity: sha512-+LpyBk7L44ZIXwz/VYfglaX/okxezESc6UxDSoyo2Ks6Jxc4Y7sGjpgU9s4PMgqgjj1gZCylTieNamqA1MF7Dg==} + '@img/sharp-libvips-linuxmusl-x64@1.3.2': + resolution: {integrity: sha512-m0lrLiUt+lBYnCFr8qV/65yMR4E/c7/wf78I5eKTdkEakFAlZ9QlzEM3QIhhAwVeUhLAHLcCq7a7Vszq/oFNZQ==} cpu: [x64] os: [linux] libc: [musl] - '@img/sharp-linux-arm64@0.34.5': - resolution: {integrity: sha512-bKQzaJRY/bkPOXyKx5EVup7qkaojECG6NLYswgktOZjaXecSAeCWiZwwiFf3/Y+O1HrauiE3FVsGxFg8c24rZg==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-linux-arm64@0.35.3': + resolution: {integrity: sha512-QgKDspHPnrU+GQ55XPhGwyhC8acLVOOSyAvo1oVfFmrIXLkDNmGWzAfDZ4xK8oSA1qBQrALcHX0G5UZni/SuFQ==} + engines: {node: '>=20.9.0'} cpu: [arm64] os: [linux] libc: [glibc] - '@img/sharp-linux-arm@0.34.5': - resolution: {integrity: sha512-9dLqsvwtg1uuXBGZKsxem9595+ujv0sJ6Vi8wcTANSFpwV/GONat5eCkzQo/1O6zRIkh0m/8+5BjrRr7jDUSZw==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-linux-arm@0.35.3': + resolution: {integrity: sha512-affVWCTLooy8TSxbDx2qkzuDeaWLNVBA+P//FNBirHsXpP2fuBhk5AuboYUnrDnzoXes8GFjpTx0SBFOCRg+FA==} + engines: {node: '>=20.9.0'} cpu: [arm] os: [linux] libc: [glibc] - '@img/sharp-linux-ppc64@0.34.5': - resolution: {integrity: sha512-7zznwNaqW6YtsfrGGDA6BRkISKAAE1Jo0QdpNYXNMHu2+0dTrPflTLNkpc8l7MUP5M16ZJcUvysVWWrMefZquA==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-linux-ppc64@0.35.3': + resolution: {integrity: sha512-sMd8rDxmpLOwv/7N44klFjOD5DUO7FLdjiXDI0hoxYaf7Ar262dQIEkosE98bps+5HPLtp/EvNqeqQtOycP/IA==} + engines: {node: '>=20.9.0'} cpu: [ppc64] os: [linux] libc: [glibc] - '@img/sharp-linux-riscv64@0.34.5': - resolution: {integrity: sha512-51gJuLPTKa7piYPaVs8GmByo7/U7/7TZOq+cnXJIHZKavIRHAP77e3N2HEl3dgiqdD/w0yUfiJnII77PuDDFdw==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-linux-riscv64@0.35.3': + resolution: {integrity: sha512-0Eob78yjlYPfL5vMNWAW55l3R9Y6BQS/gOfe0ZcP9mEz9ohhKSt4im1hayiknXgf8AWrFqMvJcKIdmLmEe7yeQ==} + engines: {node: '>=20.9.0'} cpu: [riscv64] os: [linux] libc: [glibc] - '@img/sharp-linux-s390x@0.34.5': - resolution: {integrity: sha512-nQtCk0PdKfho3eC5MrbQoigJ2gd1CgddUMkabUj+rBevs8tZ2cULOx46E7oyX+04WGfABgIwmMC0VqieTiR4jg==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-linux-s390x@0.35.3': + resolution: {integrity: sha512-KgAxQ0DxpNOq1rG2t5cgTgShJFGSuU7XO45cqC+1NVOuZnP6tlgZRuSYOfNupGkHID0o3cJOsw4DVeJpMovcGw==} + engines: {node: '>=20.9.0'} cpu: [s390x] os: [linux] libc: [glibc] - '@img/sharp-linux-x64@0.34.5': - resolution: {integrity: sha512-MEzd8HPKxVxVenwAa+JRPwEC7QFjoPWuS5NZnBt6B3pu7EG2Ge0id1oLHZpPJdn3OQK+BQDiw9zStiHBTJQQQQ==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-linux-x64@0.35.3': + resolution: {integrity: sha512-8pqvxubL2PGdhlPy6GLqzDYMUjyRmKAwKHYKixpdJYBUK7PJ0C029XdsnpFIdgRZG68fZiGdHVWcKPvtiPB4cA==} + engines: {node: '>=20.9.0'} cpu: [x64] os: [linux] libc: [glibc] - '@img/sharp-linuxmusl-arm64@0.34.5': - resolution: {integrity: sha512-fprJR6GtRsMt6Kyfq44IsChVZeGN97gTD331weR1ex1c1rypDEABN6Tm2xa1wE6lYb5DdEnk03NZPqA7Id21yg==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-linuxmusl-arm64@0.35.3': + resolution: {integrity: sha512-Vz0iQjzzcSX3HCbfwFfCSG/9SCIqyO0mH2sXyiHaAYfBk0cRsCWXRyQYX0ovCK/PAQBbTzQ0dsPQHh5MAFL59w==} + engines: {node: '>=20.9.0'} cpu: [arm64] os: [linux] libc: [musl] - '@img/sharp-linuxmusl-x64@0.34.5': - resolution: {integrity: sha512-Jg8wNT1MUzIvhBFxViqrEhWDGzqymo3sV7z7ZsaWbZNDLXRJZoRGrjulp60YYtV4wfY8VIKcWidjojlLcWrd8Q==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-linuxmusl-x64@0.35.3': + resolution: {integrity: sha512-6O1NPKcDVj9QEdg7Hx549EX8U0rp6yXQERqru6yRN7fGBn32UvIRJUlWnk+8xDCiG76hXVBbX82NZ/ZKr0euIg==} + engines: {node: '>=20.9.0'} cpu: [x64] os: [linux] libc: [musl] - '@img/sharp-wasm32@0.34.5': - resolution: {integrity: sha512-OdWTEiVkY2PHwqkbBI8frFxQQFekHaSSkUIJkwzclWZe64O1X4UlUjqqqLaPbUpMOQk6FBu/HtlGXNblIs0huw==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-wasm32@0.35.3': + resolution: {integrity: sha512-cZ0XkcYGpHZkqW6iCkqTcmUC0CD9DhD5d/qeZlZkfRBn6GnHniZXLUo5+9xw8Iv76YE6LQFN9YNBlKREcCG76w==} + engines: {node: '>=20.9.0'} + + '@img/sharp-webcontainers-wasm32@0.35.3': + resolution: {integrity: sha512-2rnq7bX3NzeR2T4YWgz8qiG4h3TSdMe+vN1iQXpJleSJ3SM5zQ8Fy2SyyXAWlbxpEZ2Y+Z4u1BePgJEYbSy80Q==} + engines: {node: '>=20.9.0'} cpu: [wasm32] - '@img/sharp-win32-arm64@0.34.5': - resolution: {integrity: sha512-WQ3AgWCWYSb2yt+IG8mnC6Jdk9Whs7O0gxphblsLvdhSpSTtmu69ZG1Gkb6NuvxsNACwiPV6cNSZNzt0KPsw7g==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-win32-arm64@0.35.3': + resolution: {integrity: sha512-4bPwFdMbeC4JQ8L8LOyWp6nsHcboP5fxkp6iPOXz2Vg49R42TuMs2whkJ5OAP4/Ul035qOzy0AecOF9VOscn4w==} + engines: {node: '>=20.9.0'} cpu: [arm64] os: [win32] - '@img/sharp-win32-ia32@0.34.5': - resolution: {integrity: sha512-FV9m/7NmeCmSHDD5j4+4pNI8Cp3aW+JvLoXcTUo0IqyjSfAZJ8dIUmijx1qaJsIiU+Hosw6xM5KijAWRJCSgNg==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-win32-ia32@0.35.3': + resolution: {integrity: sha512-r53mXsBN6lFUDiST764SvgwUdHAqM4rPAiDzAmf4fLoB6X/rkfyTrLCg6+g17wJJiCmB3JYgHuUldCWUIRFSXw==} + engines: {node: ^20.9.0} cpu: [ia32] os: [win32] - '@img/sharp-win32-x64@0.34.5': - resolution: {integrity: sha512-+29YMsqY2/9eFEiW93eqWnuLcWcufowXewwSNIT6UwZdUUCrM3oFjMWH/Z6/TMmb4hlFenmfAVbpWeup2jryCw==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + '@img/sharp-win32-x64@0.35.3': + resolution: {integrity: sha512-D4y1vNeZrIIJCN+uHaWVtH86B+aCrdMYYjicy9pXHvbGZeGYLLSd3wdVuC37FxVXlU1ARsk84eKWfWMXGYEqvA==} + engines: {node: '>=20.9.0'} cpu: [x64] os: [win32] @@ -1813,8 +1825,8 @@ packages: blake3-wasm@2.1.5: resolution: {integrity: sha512-F1+K8EbfOZE49dtoPtmxUQrpXaBIl3ICvasLh+nJta0xkz+9kF/7uet9fLnwKqhDrmj6g+6K3Tw9yQPUg2ka5g==} - brace-expansion@5.0.6: - resolution: {integrity: sha512-kLpxurY4Z4r9sgMsyG0Z9uzsBlgiU/EFKhj/h91/8yHu0edo7XuixOIH3VcJ8kkxs6/jPzoI6U9Vj3WqbMQ94g==} + brace-expansion@5.0.7: + resolution: {integrity: sha512-7oFy703dxfY3/NLxC1fh2SUCQ0H9rmAY+5EpDVfXjUTTs+HEwR2nYaqLv+GWcTsumwxPfiz6CzCNkwXwBUwqCA==} engines: {node: 18 || 20 || >=22} braces@3.0.3: @@ -2145,8 +2157,8 @@ packages: resolution: {integrity: sha512-ekilCSN1jwRvIbgeg/57YFh8qQDNbwDb9xT/qu2DAHbFFZUicIl4ygVaAvzveMhMVr3LnpSKTNnwt8PoOfmKhQ==} hasBin: true - js-yaml@4.2.0: - resolution: {integrity: sha512-ePWsvanv0DWuDRsW8dnt+R4jQ31SCRCQ7hhNcPXZPsoBZiemuZNYGf7adZdqX2D86j6rvKp3RpCxVTSb8WQlOw==} + js-yaml@4.3.0: + resolution: {integrity: sha512-1td788aAnnZ5qs7V2QIRl1owjtYpbKt749Y3xauqQgwIIGF/xXWz1wMTEBx5O3LK3lXLVuqXPdPxj2BoFHaW9Q==} hasBin: true json-buffer@3.0.1: @@ -2441,9 +2453,14 @@ packages: resolution: {integrity: sha512-F4LcB0UqUl1zErq+1nYEEzSHJnIwb3AF2XWB94b+afhrekOUijwooAYqFyRbjYkm2PAKBabx6oYv/xDxNi8IBw==} engines: {node: '>=20.0.0'} - sharp@0.34.5: - resolution: {integrity: sha512-Ou9I5Ft9WNcCbXrU9cMgPBcCK8LiwLqcbywW3t4oDV37n1pzpuNLsYiAV8eODnjbtQlSDwZ2cUEeQz4E54Hltg==} - engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0} + sharp@0.35.3: + resolution: {integrity: sha512-ej0zVHuZGHCiABXcNxeYhpRnPNPAcvbG8RMdBAhDAxLKkCRVSpK3Iyu7qbqw3JMzoj0REeM6f3tJLtVwl0023Q==} + engines: {node: '>=20.9.0'} + peerDependencies: + '@types/node': '*' + peerDependenciesMeta: + '@types/node': + optional: true shebang-command@2.0.0: resolution: {integrity: sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==} @@ -2958,98 +2975,108 @@ snapshots: '@img/colour@1.1.0': {} - '@img/sharp-darwin-arm64@0.34.5': + '@img/sharp-darwin-arm64@0.35.3': optionalDependencies: - '@img/sharp-libvips-darwin-arm64': 1.2.4 + '@img/sharp-libvips-darwin-arm64': 1.3.2 optional: true - '@img/sharp-darwin-x64@0.34.5': + '@img/sharp-darwin-x64@0.35.3': optionalDependencies: - '@img/sharp-libvips-darwin-x64': 1.2.4 + '@img/sharp-libvips-darwin-x64': 1.3.2 optional: true - '@img/sharp-libvips-darwin-arm64@1.2.4': + '@img/sharp-freebsd-wasm32@0.35.3': + dependencies: + '@img/sharp-wasm32': 0.35.3 optional: true - '@img/sharp-libvips-darwin-x64@1.2.4': + '@img/sharp-libvips-darwin-arm64@1.3.2': optional: true - '@img/sharp-libvips-linux-arm64@1.2.4': + '@img/sharp-libvips-darwin-x64@1.3.2': optional: true - '@img/sharp-libvips-linux-arm@1.2.4': + '@img/sharp-libvips-linux-arm64@1.3.2': optional: true - '@img/sharp-libvips-linux-ppc64@1.2.4': + '@img/sharp-libvips-linux-arm@1.3.2': optional: true - '@img/sharp-libvips-linux-riscv64@1.2.4': + '@img/sharp-libvips-linux-ppc64@1.3.2': optional: true - '@img/sharp-libvips-linux-s390x@1.2.4': + '@img/sharp-libvips-linux-riscv64@1.3.2': optional: true - '@img/sharp-libvips-linux-x64@1.2.4': + '@img/sharp-libvips-linux-s390x@1.3.2': optional: true - '@img/sharp-libvips-linuxmusl-arm64@1.2.4': + '@img/sharp-libvips-linux-x64@1.3.2': optional: true - '@img/sharp-libvips-linuxmusl-x64@1.2.4': + '@img/sharp-libvips-linuxmusl-arm64@1.3.2': optional: true - '@img/sharp-linux-arm64@0.34.5': + '@img/sharp-libvips-linuxmusl-x64@1.3.2': + optional: true + + '@img/sharp-linux-arm64@0.35.3': optionalDependencies: - '@img/sharp-libvips-linux-arm64': 1.2.4 + '@img/sharp-libvips-linux-arm64': 1.3.2 optional: true - '@img/sharp-linux-arm@0.34.5': + '@img/sharp-linux-arm@0.35.3': optionalDependencies: - '@img/sharp-libvips-linux-arm': 1.2.4 + '@img/sharp-libvips-linux-arm': 1.3.2 optional: true - '@img/sharp-linux-ppc64@0.34.5': + '@img/sharp-linux-ppc64@0.35.3': optionalDependencies: - '@img/sharp-libvips-linux-ppc64': 1.2.4 + '@img/sharp-libvips-linux-ppc64': 1.3.2 optional: true - '@img/sharp-linux-riscv64@0.34.5': + '@img/sharp-linux-riscv64@0.35.3': optionalDependencies: - '@img/sharp-libvips-linux-riscv64': 1.2.4 + '@img/sharp-libvips-linux-riscv64': 1.3.2 optional: true - '@img/sharp-linux-s390x@0.34.5': + '@img/sharp-linux-s390x@0.35.3': optionalDependencies: - '@img/sharp-libvips-linux-s390x': 1.2.4 + '@img/sharp-libvips-linux-s390x': 1.3.2 optional: true - '@img/sharp-linux-x64@0.34.5': + '@img/sharp-linux-x64@0.35.3': optionalDependencies: - '@img/sharp-libvips-linux-x64': 1.2.4 + '@img/sharp-libvips-linux-x64': 1.3.2 optional: true - '@img/sharp-linuxmusl-arm64@0.34.5': + '@img/sharp-linuxmusl-arm64@0.35.3': optionalDependencies: - '@img/sharp-libvips-linuxmusl-arm64': 1.2.4 + '@img/sharp-libvips-linuxmusl-arm64': 1.3.2 optional: true - '@img/sharp-linuxmusl-x64@0.34.5': + '@img/sharp-linuxmusl-x64@0.35.3': optionalDependencies: - '@img/sharp-libvips-linuxmusl-x64': 1.2.4 + '@img/sharp-libvips-linuxmusl-x64': 1.3.2 optional: true - '@img/sharp-wasm32@0.34.5': + '@img/sharp-wasm32@0.35.3': dependencies: '@emnapi/runtime': 1.11.1 optional: true - '@img/sharp-win32-arm64@0.34.5': + '@img/sharp-webcontainers-wasm32@0.35.3': + dependencies: + '@img/sharp-wasm32': 0.35.3 optional: true - '@img/sharp-win32-ia32@0.34.5': + '@img/sharp-win32-arm64@0.35.3': optional: true - '@img/sharp-win32-x64@0.34.5': + '@img/sharp-win32-ia32@0.35.3': + optional: true + + '@img/sharp-win32-x64@0.35.3': optional: true '@inquirer/ansi@2.0.7': {} @@ -3210,7 +3237,7 @@ snapshots: colorette: 2.0.20 emnapi: 1.11.1 es-toolkit: 1.49.0 - js-yaml: 4.2.0 + js-yaml: 4.3.0 obug: 2.1.3 semver: 7.8.5 typanion: 3.14.0 @@ -4137,7 +4164,7 @@ snapshots: blake3-wasm@2.1.5: {} - brace-expansion@5.0.6: + brace-expansion@5.0.7: dependencies: balanced-match: 4.0.4 @@ -4449,7 +4476,7 @@ snapshots: jiti@2.6.1: {} - js-yaml@4.2.0: + js-yaml@4.3.0: dependencies: argparse: 2.0.1 @@ -4553,18 +4580,19 @@ snapshots: miniflare@4.20260617.1: dependencies: '@cspotcode/source-map-support': 0.8.1 - sharp: 0.34.5 + sharp: 0.35.3 undici: 7.28.0 workerd: 1.20260617.1 ws: 8.21.0 youch: 4.1.0-beta.10 transitivePeerDependencies: + - '@types/node' - bufferutil - utf-8-validate minimatch@10.2.5: dependencies: - brace-expansion: 5.0.6 + brace-expansion: 5.0.7 mlly@1.8.0: dependencies: @@ -4762,36 +4790,37 @@ snapshots: serialize-javascript@7.0.5: {} - sharp@0.34.5: + sharp@0.35.3: dependencies: '@img/colour': 1.1.0 detect-libc: 2.1.2 semver: 7.8.5 optionalDependencies: - '@img/sharp-darwin-arm64': 0.34.5 - '@img/sharp-darwin-x64': 0.34.5 - '@img/sharp-libvips-darwin-arm64': 1.2.4 - '@img/sharp-libvips-darwin-x64': 1.2.4 - '@img/sharp-libvips-linux-arm': 1.2.4 - '@img/sharp-libvips-linux-arm64': 1.2.4 - '@img/sharp-libvips-linux-ppc64': 1.2.4 - '@img/sharp-libvips-linux-riscv64': 1.2.4 - '@img/sharp-libvips-linux-s390x': 1.2.4 - '@img/sharp-libvips-linux-x64': 1.2.4 - '@img/sharp-libvips-linuxmusl-arm64': 1.2.4 - '@img/sharp-libvips-linuxmusl-x64': 1.2.4 - '@img/sharp-linux-arm': 0.34.5 - '@img/sharp-linux-arm64': 0.34.5 - '@img/sharp-linux-ppc64': 0.34.5 - '@img/sharp-linux-riscv64': 0.34.5 - '@img/sharp-linux-s390x': 0.34.5 - '@img/sharp-linux-x64': 0.34.5 - '@img/sharp-linuxmusl-arm64': 0.34.5 - '@img/sharp-linuxmusl-x64': 0.34.5 - '@img/sharp-wasm32': 0.34.5 - '@img/sharp-win32-arm64': 0.34.5 - '@img/sharp-win32-ia32': 0.34.5 - '@img/sharp-win32-x64': 0.34.5 + '@img/sharp-darwin-arm64': 0.35.3 + '@img/sharp-darwin-x64': 0.35.3 + '@img/sharp-freebsd-wasm32': 0.35.3 + '@img/sharp-libvips-darwin-arm64': 1.3.2 + '@img/sharp-libvips-darwin-x64': 1.3.2 + '@img/sharp-libvips-linux-arm': 1.3.2 + '@img/sharp-libvips-linux-arm64': 1.3.2 + '@img/sharp-libvips-linux-ppc64': 1.3.2 + '@img/sharp-libvips-linux-riscv64': 1.3.2 + '@img/sharp-libvips-linux-s390x': 1.3.2 + '@img/sharp-libvips-linux-x64': 1.3.2 + '@img/sharp-libvips-linuxmusl-arm64': 1.3.2 + '@img/sharp-libvips-linuxmusl-x64': 1.3.2 + '@img/sharp-linux-arm': 0.35.3 + '@img/sharp-linux-arm64': 0.35.3 + '@img/sharp-linux-ppc64': 0.35.3 + '@img/sharp-linux-riscv64': 0.35.3 + '@img/sharp-linux-s390x': 0.35.3 + '@img/sharp-linux-x64': 0.35.3 + '@img/sharp-linuxmusl-arm64': 0.35.3 + '@img/sharp-linuxmusl-x64': 0.35.3 + '@img/sharp-webcontainers-wasm32': 0.35.3 + '@img/sharp-win32-arm64': 0.35.3 + '@img/sharp-win32-ia32': 0.35.3 + '@img/sharp-win32-x64': 0.35.3 shebang-command@2.0.0: dependencies: @@ -5044,6 +5073,7 @@ snapshots: optionalDependencies: fsevents: 2.3.3 transitivePeerDependencies: + - '@types/node' - bufferutil - utf-8-validate diff --git a/pnpm-workspace.yaml b/pnpm-workspace.yaml index dfdf65d52188..3286124cbe58 100644 --- a/pnpm-workspace.yaml +++ b/pnpm-workspace.yaml @@ -12,5 +12,8 @@ allowBuilds: workerd: true overrides: + brace-expansion@>=3.0.0 <5.0.7: 5.0.7 esbuild@>=0.27.3 <0.28.1: '>=0.28.1' + js-yaml@>=4.0.0 <4.3.0: 4.3.0 + sharp@<0.35.0: 0.35.3 ws@>=8.0.0 <8.20.1: '>=8.20.1'