From 25b6e75cedef3d8097e46c8ffdad31a0b10e29a3 Mon Sep 17 00:00:00 2001 From: Renaud Laborbe <150821561+BluegReeno@users.noreply.github.com> Date: Fri, 24 Jul 2026 20:50:21 +0200 Subject: [PATCH] fix(edifice-map-generator): restore deno check on the PNG codec MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `main` has been red since 48f89fd. Committing the deployed v10 of this function (444fa3d) brought in the pure-TS PNG codec, whose stream helpers do not type-check under Deno 2.x — 2 × TS2345 on `deno check index.ts`. Every PR since then inherits the failure through its merge with main. Two type facts, neither cosmetic: 1. CompressionStream / DecompressionStream declare `writable: WritableStream`, wider than Uint8Array — so a `TransformStream` parameter asked for something narrower than either class provides, and neither was assignable. 2. Since TypeScript 5.7 typed arrays are generic over their backing buffer: bare `Uint8Array` means `Uint8Array`, which admits SharedArrayBuffer, while `BufferSource` requires `ArrayBufferView`. Fixed by typing the codec path `Uint8Array` and widening the transform parameter to `TransformStream`. This states that these buffers are never shared — already true, every one comes from `new Uint8Array(n)` or a `Response.arrayBuffer()`. A cast would have silenced the checker without saying so. Types only: the diff touches three signatures and no executable line, so the deployed function is unaffected. Verified with the CI's own toolchain (`denoland/deno` image, `deno check index.ts`): edifice-map-generator goes from 2 errors to clean, hal-mcp stays clean. Co-Authored-By: Claude Opus 4.8 --- .../functions/edifice-map-generator/index.ts | 22 ++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/supabase/functions/edifice-map-generator/index.ts b/supabase/functions/edifice-map-generator/index.ts index 95ced7f..e2c4866 100644 --- a/supabase/functions/edifice-map-generator/index.ts +++ b/supabase/functions/edifice-map-generator/index.ts @@ -304,18 +304,30 @@ function crc32(data: Uint8Array): number { return (c ^ 0xFFFFFFFF) >>> 0; } -async function zlibDecompress(data: Uint8Array): Promise { +async function zlibDecompress(data: Uint8Array): Promise> { return streamTransform(new DecompressionStream("deflate"), data); } -async function zlibCompress(data: Uint8Array): Promise { +async function zlibCompress(data: Uint8Array): Promise> { return streamTransform(new CompressionStream("deflate"), data); } +// Two type facts drive these signatures under Deno 2.x / TypeScript 5.7, and neither is +// cosmetic: +// 1. CompressionStream and DecompressionStream declare `writable: WritableStream`, +// which is wider than Uint8Array — so a `TransformStream` +// parameter asked for something narrower than either class provides. +// 2. Since TS 5.7 typed arrays are generic over their backing buffer: bare `Uint8Array` +// means `Uint8Array`, which admits SharedArrayBuffer, while +// `BufferSource` requires `ArrayBufferView`. So a bare Uint8Array is not +// writable to these streams. +// Hence `Uint8Array` throughout the PNG codec path: it states that these buffers +// are never shared, which is already true — every one of them comes from `new Uint8Array(n)` +// or a `Response.arrayBuffer()`. A cast would have silenced the checker without saying so. async function streamTransform( - xform: TransformStream, - data: Uint8Array, -): Promise { + xform: TransformStream, + data: Uint8Array, +): Promise> { const writer = xform.writable.getWriter(); const reader = xform.readable.getReader(); const chunks: Uint8Array[] = [];