@zip.js/zip.js 2.11.0 → 2.11.2

package/BENCHMARKS.md

@@ -15,8 +15,10 @@ should not trust anyone's benchmark (including this one) without reproducing it.
 > **without spawning a single Web Worker** — it lets the platform's native
 > `CompressionStream` run on the threadpool while you simply issue concurrent `add()`
 > calls. It also streams arbitrarily large files at a flat, low memory ceiling. For
-> deflating thousands of tiny buffers in one shot, **fflate** remains the throughput
-> and footprint champion. Against native tooling, zip.js on a modern runtime is a bit
+> archives made of thousands of tiny entries, **fflate** is several times faster and much
+> lighter — but that gap is zip.js's per-entry orchestration, not its codec: measured on
+> their own, the codecs are the other way round (see [Codecs](#codecs-compared-at-equal-output-size)).
+> Against native tooling, zip.js on a modern runtime is a bit
 > faster *and* tighter than 7-Zip's fast mode on single-file streaming; 7-Zip keeps a
 > real edge only on thousands of tiny files.
 
@@ -25,12 +27,13 @@ should not trust anyone's benchmark (including this one) without reproducing it.
 | | |
 |---|---|
 | Machine | Apple M2, 8 cores (4 performance + 4 efficiency), 16 GB RAM |
-| OS | macOS 26.5.1 (arm64) |
-| Runtime | Node.js v24.12.0 |
-| zip.js | 2.8.29 |
+| OS | macOS 26.6.2 (arm64) |
+| Runtime | Node.js v26.7.0 |
+| zip.js | 2.11.2 |
 | jszip | 3.10.1 |
 | fflate | 0.8.3 |
 | archiver | 8.0.0 |
+| Measured | 2026-09-06, except the 7-Zip section (see its own note) |
 
 ## Method
 
@@ -40,11 +43,15 @@ should not trust anyone's benchmark (including this one) without reproducing it.
 - **Timing.** `performance.now()` around the measured operation only. Every combination
   runs **3 times**; the table reports the **median**.
 - **Memory.** Peak resident set size (RSS) reported by `/usr/bin/time -l`. The "peak"
-  column is the delta over an empty-process baseline (~42 MB), i.e. the memory
-  attributable to the work.
-- **Fair work.** All libraries compress at **DEFLATE level 6**. Output sizes are shown
-  so you can confirm each library did equivalent work. The corpus is generated from a
-  seeded PRNG, so every library sees byte-for-byte identical input.
+  column is the delta over an empty-process baseline (~50 MB on this runtime), i.e. the
+  memory attributable to the work.
+- **Fair work.** All libraries compress at **DEFLATE level 6**, and output sizes are shown
+  next to the times. Read them: a "level" is not a unit shared between libraries. zlib's
+  level 6 and fflate's level 6 are different parameter sets, so the two do not produce the
+  same amount of compression and a time is only comparable next to the size it achieved.
+  The [Codecs](#codecs-compared-at-equal-output-size) section compares them by output size
+  instead, which is the only axis on which "faster" means anything. The corpus is generated
+  from a seeded PRNG, so every library sees byte-for-byte identical input.
 - **zip.js modes.** zip.js is measured both **single-threaded** (apples-to-apples with
   the single-threaded libraries) and with its **Web Worker** pool, so the worker
   overhead is never hidden.
@@ -54,26 +61,31 @@ should not trust anyone's benchmark (including this one) without reproducing it.
 Level-6 DEFLATE, one entry (or one batch) compressed in the main thread. This is the
 apples-to-apples comparison against the single-threaded libraries.
 
+Time, with the size each library produced — the two are only meaningful together.
+
 | Workload | @zip.js/zip.js | jszip | fflate | archiver |
 |---|--:|--:|--:|--:|
-| Compressible text (20 MB) | **795 ms** | 1770 ms | 953 ms | 720 ms |
-| Incompressible data (20 MB) | 446 ms | 883 ms | **306 ms** | 366 ms |
-| Already-compressed media (20 MB) | 452 ms | 886 ms | **298 ms** | 358 ms |
-| 5,000 files × ~2 KB | 845 ms | 887 ms | **287 ms** | 419 ms |
+| Compressible text (20 MB) | 703 ms / 6.1 MB | 1714 ms / 6.2 MB | 908 ms / 6.3 MB | **702 ms** / 6.1 MB |
+| Incompressible data (20 MB) | 364 ms / 21.0 MB | 858 ms / 21.0 MB | **298 ms** / 21.0 MB | 357 ms / 21.0 MB |
+| Already-compressed media (20 MB) | 362 ms / 21.0 MB | 860 ms / 21.0 MB | **297 ms** / 21.0 MB | 356 ms / 21.0 MB |
+| 5,000 files × ~2 KB | 834 ms / 4.9 MB | 826 ms / 4.7 MB | **305 ms** / 4.8 MB | 431 ms / 4.8 MB |
 
 Peak memory for the same runs (Δ over baseline):
 
 | Workload | @zip.js/zip.js | jszip | fflate | archiver |
 |---|--:|--:|--:|--:|
-| Compressible text (20 MB) | 92 MB | 65 MB | **60 MB** | 82 MB |
-| Incompressible data (20 MB) | 141 MB | 93 MB | 106 MB | **83 MB** |
-| Already-compressed media (20 MB) | 142 MB | 94 MB | 106 MB | **83 MB** |
-| 5,000 files × ~2 KB | 266 MB | 270 MB | **102 MB** | 118 MB |
-
-zip.js is fastest on compressible text and competitive with archiver elsewhere, at
-roughly comparable compressed sizes. **fflate** is the clear winner on raw throughput
-and footprint for incompressible data and for large numbers of tiny files — if that is
-your workload, use fflate.
+| Compressible text (20 MB) | 90 MB | 69 MB | **62 MB** | 72 MB |
+| Incompressible data (20 MB) | 153 MB | 92 MB | 108 MB | **81 MB** |
+| Already-compressed media (20 MB) | 154 MB | 93 MB | 108 MB | **74 MB** |
+| 5,000 files × ~2 KB | 252 MB | 267 MB | **102 MB** | 137 MB |
+
+On compressible text zip.js and archiver are tied (703 ms against 702 ms, inside the
+noise) and both produce the smallest archive; fflate is 29 % slower here *and* 3 % larger,
+which is the level-6-is-not-a-unit effect described above. On incompressible data — where
+no codec has anything to do — fflate wins on both axes. On 5,000 tiny files fflate is 2.7×
+faster than zip.js and uses a third of the memory; that gap is per-entry orchestration
+(worker round trips, header writes, one stream per entry), not codec speed, as the
+[Codecs](#codecs-compared-at-equal-output-size) section shows.
 
 ## Parallelism & codec backends — 8 files × 8 MB, single process
 
@@ -82,26 +94,29 @@ in a **plain Node process** (no worker threads unless noted). zip.js can select
 codec backend at runtime — native `CompressionStream`, the bundled WebAssembly zlib, or
 a pure-JavaScript zlib port — and it can issue `add()` calls concurrently.
 
-| Configuration | Median time | vs jszip |
-|---|--:|--:|
-| **zip.js — `CompressionStream`, concurrent `add()`** | **657 ms** | **8.8×** |
-| fflate — async (its own worker pool) | 729 ms | 7.9× |
-| archiver — Node zlib (libuv threadpool) | 2266 ms | 2.5× |
-| zip.js — `CompressionStream`, sequential | 2453 ms | 2.3× |
-| fflate — `zipSync` (single thread) | 3103 ms | 1.9× |
-| zip.js — WASM zlib | 4176 ms | 1.4× |
-| zip.js — pure-JS zlib | 4709 ms | 1.2× |
-| jszip (pako, single thread) | 5758 ms | 1.0× |
-
-**The point:** zip.js with the native `CompressionStream` goes from **2453 ms
-sequential to 657 ms with concurrent `add()` — a 3.7× speedup — using no Web Workers at
+| Configuration | Median time | Output | vs jszip |
+|---|--:|--:|--:|
+| **zip.js — `CompressionStream`, concurrent `add()`** | **607 ms** | 19.6 MB | **9.3×** |
+| fflate — async (its own worker pool) | 733 ms | 20.0 MB | 7.7× |
+| zip.js — `CompressionStream`, sequential | 2214 ms | 19.6 MB | 2.6× |
+| archiver — Node zlib (libuv threadpool) | 2278 ms | 19.6 MB | 2.5× |
+| fflate — `zipSync` (single thread) | 3118 ms | 20.0 MB | 1.8× |
+| zip.js — WASM zlib | 3358 ms | 19.7 MB | 1.7× |
+| zip.js — pure-JS zlib | 3840 ms | 19.7 MB | 1.5× |
+| jszip (pako, single thread) | 5671 ms | 19.7 MB | 1.0× |
+
+The two fflate rows produce 20.0 MB where every other row produces 19.6–19.7 MB, i.e. ~2 %
+more, so they are not doing quite the same work as the rows above and below them.
+
+**The point:** zip.js with the native `CompressionStream` goes from **2214 ms
+sequential to 607 ms with concurrent `add()` — a 3.6× speedup — using no Web Workers at
 all.** The native codec runs on the platform's threadpool, so independent entries
 compress on multiple cores while your code stays on the main thread. That makes it the
-fastest configuration measured, narrowly ahead of fflate's dedicated worker pool.
+fastest configuration measured, ahead of fflate's dedicated worker pool.
 
 One honest caveat, visible in the table: **only the native `CompressionStream` backend
 parallelizes this way.** The WASM and pure-JS backends run synchronously on the main
-thread, so concurrent `add()` does not speed them up (4176 ms and 4709 ms whether
+thread, so concurrent `add()` does not speed them up (3358 ms and 3840 ms whether
 sequential or "parallel"). Use those backends when a native `CompressionStream` is
 unavailable or when you need byte-identical zlib output; use the native backend when you
 want this parallelism.
@@ -141,6 +156,50 @@ Safari/WebKit, also set `useWebWorkers: true`. Web Workers are the portable way
 this parallelism on any runtime — and the only way once you use a non-default level
 (which switches to the WASM codec).
 
+## Codecs, compared at equal output size
+
+The tables above compare *libraries* — a whole zip pipeline, at each library's default
+"level 6". This one compares only the **codecs**, on the same 20 MB buffer with no zip
+container around them, and sorts by output size rather than by level. That matters because
+zlib's level 6 and fflate's level 6 are different parameter sets: matched by level, the
+comparison silently reads a ratio difference as a speed difference.
+
+`frontier` marks a row that nothing smaller beats on time.
+
+| Codec | Setting | Output | Ratio | Time | Throughput | |
+|---|---|--:|--:|--:|--:|---|
+| WASM zlib | level 8 | 6,115,980 | 3.429 | 1466 ms | 13.6 MB/s | frontier |
+| `CompressionStream` | no level control | 6,120,503 | 3.426 | 692 ms | 28.9 MB/s | frontier |
+| WASM zlib | level 6 | 6,165,103 | 3.402 | 1023 ms | 19.5 MB/s | |
+| fflate | level 8 — its best | 6,239,025 | 3.361 | 750 ms | 26.7 MB/s | |
+| fflate | level 6 | 6,257,881 | 3.351 | 738 ms | 27.1 MB/s | |
+| WASM zlib | level 5 | 6,562,182 | 3.196 | 494 ms | 40.5 MB/s | frontier |
+| fflate | level 5 | 6,648,574 | 3.154 | 534 ms | 37.4 MB/s | |
+| WASM zlib | level 4 | 6,907,987 | 3.036 | 276 ms | 72.4 MB/s | frontier |
+| fflate | level 1 | 7,261,700 | 2.888 | 316 ms | 63.3 MB/s | |
+| WASM zlib | level 1 | 7,531,042 | 2.785 | 177 ms | 113.1 MB/s | frontier |
+
+The pure-JS port produces byte-identical output to the WASM codec at every level and is
+1.2–2× slower; the full 28-row table is in `benchmarks/results/codecs-results.json`.
+
+Two things to take from it. **fflate never lands on the frontier here** — at every size it
+reaches, one of zip.js's codecs gets there sooner — and above ratio 3.361 it has no setting
+at all, while the WASM codec keeps going to 3.429. Second, the level numbers really are
+incomparable: fflate's level 6 falls between zlib's levels 5 and 6 on ratio, which is
+exactly why the library tables above show it as both faster *and* larger.
+
+Decompression of the same stream:
+
+| Codec | Time | Throughput |
+|---|--:|--:|
+| WASM zlib | **46 ms** | 434.7 MB/s |
+| `DecompressionStream` | 56 ms | 354.6 MB/s |
+| pure-JS zlib | 110 ms | 181.5 MB/s |
+| fflate | 123 ms | 162.7 MB/s |
+
+The WASM inflate is 2.7× faster than fflate's, and faster than Node's own
+`DecompressionStream`, since the Chromium `inffast_chunk` port landed in 2.11.0.
+
 ## Decompression
 
 Level-6 archives, read back and fully materialized. archiver has no unzip API, so it is
@@ -148,8 +207,8 @@ excluded.
 
 | Workload | @zip.js/zip.js | jszip | fflate |
 |---|--:|--:|--:|
-| Compressible text (20 MB) | **65 ms** | 143 ms | 82 ms |
-| 5,000 files × ~2 KB | 565 ms | 453 ms | **89 ms** |
+| Compressible text (20 MB) | **66 ms** | 133 ms | 117 ms |
+| 5,000 files × ~2 KB | 603 ms | 445 ms | **104 ms** |
 
 zip.js has the fastest large-stream decompression. On thousands of tiny entries the
 per-entry setup cost dominates and **fflate is dramatically faster and lighter** — again
@@ -160,17 +219,17 @@ the right tool when you are unpacking many small files.
 The input is streamed from disk and the archive is streamed back to disk; neither is
 ever fully held in memory (for the libraries that support it).
 
-| Library | Median time | Peak memory |
-|---|--:|--:|
-| archiver | 9183 ms | 111 MB |
-| zip.js (workers) | 9893 ms | **99 MB** |
-| zip.js (1 thread) | 10110 ms | **99 MB** |
-| fflate | 10613 ms | 87 MB |
-| jszip | 22358 ms | 527 MB |
-
-zip.js, fflate and archiver all hold memory **flat** while streaming — zip.js peaks at
-~99 MB regardless of the 256 MB input, thanks to real backpressure through the
-compression pipeline. **jszip buffers the entire file** and needs ~527 MB, at more than
+| Library | Median time | Peak memory (Δ) | Output |
+|---|--:|--:|--:|
+| zip.js (workers) | **8888 ms** | 60 MB | 78.3 MB |
+| archiver | 9150 ms | 71 MB | 78.3 MB |
+| zip.js (1 thread) | 9296 ms | 62 MB | 78.3 MB |
+| fflate | 12549 ms | **43 MB** | 80.2 MB |
+| jszip | 22014 ms | 484 MB | 78.9 MB |
+
+zip.js, fflate and archiver all hold memory **flat** while streaming — zip.js peaks ~60 MB
+over baseline regardless of the 256 MB input, thanks to real backpressure through the
+compression pipeline. **jszip buffers the entire file** and needs ~484 MB, at more than
 twice the wall-clock time. If you process files that do not fit comfortably in memory,
 avoid jszip.
 
@@ -179,7 +238,10 @@ avoid jszip.
 How far is zip.js from a native archiver? [`benchmarks/bench-7z.js`](benchmarks/bench-7z.js)
 compares it against the `7zz` CLI (7-Zip 25.01), disk-to-disk on both sides, under Deno
 2.9.3 and Bun 1.3.14 (both runtimes agree within noise; Deno numbers shown). 7-Zip
-timings include process spawn (~ms).
+timings include process spawn (~ms). Unlike the tables above, this section and the next
+were measured in July 2026 with zip.js 2.8.29 and have not been re-run; they compare
+zip.js against tools that have not changed, so they age slowly, but treat the zip.js
+columns as a floor rather than as current.
 
 One comparison is impossible to make perfectly fair: **no 7-Zip preset runs zlib's
 algorithm.** `-mx=5+` is a near-optimal parser (much slower, smaller output) and
@@ -225,7 +287,6 @@ file, one thread, level-6-class output everywhere:
 | zlib-ng — Deno & Bun `CompressionStream` | **4.8–5.1 s** | 79.4 MB |
 | Chromium zlib — Node `CompressionStream` / `node:zlib` | 8.9 s | 78.3 MB |
 | classic zlib — Apple `gzip -6` | 12.5 s | 78.9 MB |
-| classic zlib compiled to WASM — zip.js `useCompressionStream: false` | ~16 s | 78.9 MB |
 | (reference) 7-Zip `-mx=6` | 33.5 s | 73.6 MB |
 
 Verified in the runtimes' sources: Deno builds `flate2` with vendored
@@ -239,11 +300,13 @@ Consequences worth knowing:
 - **The same zip.js code runs ~1.75× faster on Deno/Bun than on Node** for bulk
   compression. A "zip.js is fast/slow" measurement is often really a statement about
   the host's zlib — and the Node tables above are the *pessimistic* end.
-- **The WASM backend is the portability floor, not a peer**: classic zlib plus ~30 %
-  WebAssembly overhead ≈ 3× slower than native on compress. Decompression barely
-  suffers (inflate is cheap — within ~10 % of native). It still lands mid-curve
-  against 7-Zip: 16 s / 78.9 MB sits between `-mx=1` (5.9 s / 86.7 MB) and `-mx=6`
-  (33.5 s / 73.6 MB).
+- **The WASM backend is a fallback, but a much closer one since 2.11.0.** It used to be
+  classic zlib plus WebAssembly overhead, ~3× slower than native on compress. It now
+  carries Chromium's zlib: on the codec table above it deflates at level 6 in 1023 ms
+  against the native `CompressionStream`'s 692 ms — 1.5× slower for 0.7 % more bytes — and
+  it *inflates faster* than the native `DecompressionStream` (46 ms against 56 ms). Reach
+  for it when no native `CompressionStream` exists, when you need a specific level, or
+  when you need output that does not vary with the host's zlib.
 - Output sizes across the zlib family are interchangeable (78–79 MB): it is one
   algorithm at four levels of implementation tuning. zip.js inherits whichever the
   host provides — including future upgrades, for free.
@@ -255,8 +318,11 @@ Consequences worth knowing:
   low-memory streaming of huge files, and the broadest ZIP feature set in one library —
   AES & ZipCrypto encryption, Zip64, split/multi-volume archives, and an optional Web
   Worker pool.
-- **Choose fflate** when you deflate thousands of tiny buffers in a single call and want
-  the smallest memory footprint and the highest raw synchronous throughput.
+- **Choose fflate** for archives of thousands of tiny entries, and when you want the
+  smallest memory footprint and the smallest bundle. Note what it does *not* buy you: at
+  equal output size its codec is not the fastest one here (see
+  [Codecs](#codecs-compared-at-equal-output-size)), so the win is fflate's very low
+  per-entry cost, not its deflate.
 - **archiver** is a solid streaming compressor on Node but cannot read archives.
 - **jszip** is convenient but the slowest here and buffers whole files in memory.
 
@@ -271,6 +337,7 @@ npm install            # jszip, fflate, archiver (zip.js is used from the repo)
 npm run corpus         # generate the deterministic datasets under .corpus/
 node bench.js          # the head-to-head tables (compress / decompress / disk streaming)
 node bench-backends.js # the parallelism & codec-backend matrix
+node bench-codecs.js   # the codecs alone, sorted by output size
 deno run -A bench-7z.js # zip.js vs the 7zz CLI (also: bun bench-7z.js)
 ```
 

package/deno.json

@@ -1,6 +1,6 @@
 {
 	"name": "@zip-js/zip-js",
-	"version": "2.11.0",
+	"version": "2.11.2",
 	"exports": {
 		".": "./index.js",
 		"./external": "./lib/zip-fs-external.js",

package/dist/zip-core-external.js

@@ -3639,11 +3639,10 @@ class Reader extends Stream {
 				const data = await readUint8Array(reader, offset + chunkOffset, dataSize);
 				if (data.length) {
 					controller.enqueue(data);
+					chunkOffset += data.length;
 				}
-				if ((chunkOffset + chunkSize >= size) || (!data.length && dataSize)) {
+				if ((size !== UNDEFINED_VALUE && chunkOffset >= size) || (!data.length && dataSize)) {
 					controller.close();
-				} else {
-					chunkOffset += chunkSize;
 				}
 			}
 		});
@@ -6334,6 +6333,7 @@ class ZipWriter {
 			pendingAddFileCalls: new Set(),
 			pendingErrors: [],
 			bufferedWrites: 0,
+			directWrites: 0,
 			lastFileEntry: UNDEFINED_VALUE
 		});
 	}
@@ -7109,6 +7109,7 @@ async function getFileEntry(zipWriter, name, reader, entryInfo, options) {
 	const usdz = zipWriter.options[OPTION_USDZ];
 	let fileEntry = pendingFileEntry;
 	let bufferedWrite;
+	let directWrite;
 	let releaseLockWriter;
 	let writingBufferedEntryData;
 	let writingEntryData;
@@ -7118,7 +7119,7 @@ async function getFileEntry(zipWriter, name, reader, entryInfo, options) {
 	const lockPreviousFileEntry = keepOrder && previousFileEntry ? previousFileEntry.lockFileEntry : UNDEFINED_VALUE;
 	fileEntries.set(name, fileEntry);
 	try {
-		if (options.bufferedWrite || !keepOrder || zipWriter.writerLocked || zipWriter.bufferedWrites || (!dataDescriptor && !emptyEntry)) {
+		if (options.bufferedWrite || !keepOrder || zipWriter.writerLocked || zipWriter.bufferedWrites || zipWriter.directWrites || (!dataDescriptor && !emptyEntry)) {
 			bufferedWrite = true;
 			zipWriter.bufferedWrites++;
 			if (options.createTempStream) {
@@ -7129,6 +7130,8 @@ async function getFileEntry(zipWriter, name, reader, entryInfo, options) {
 			fileWriter.size = 0;
 			await initStream(writer);
 		} else {
+			directWrite = true;
+			zipWriter.directWrites++;
 			fileWriter = writer;
 			await lockPreviousFileEntry;
 			await requestLockWriter();
@@ -7207,6 +7210,9 @@ async function getFileEntry(zipWriter, name, reader, entryInfo, options) {
 		if (bufferedWrite) {
 			zipWriter.bufferedWrites--;
 		}
+		if (directWrite) {
+			zipWriter.directWrites--;
+		}
 		if (releaseLockFileEntry) {
 			releaseLockFileEntry(lockPreviousFileEntry);
 		}
@@ -7351,8 +7357,8 @@ async function createFileEntry(reader, writer, { diskNumberStart, lockFileEntry
 	}
 	const { writable } = writer;
 	if (reader) {
-		const readable = toCompatibleReadable(createReadable(reader));
 		const size = reader.size;
+		const readable = toCompatibleReadable(createReadable(reader, { size }));
 		const workerOptions = {
 			options: {
 				codecType: CODEC_DEFLATE,
@@ -8531,7 +8537,7 @@ function formatSupported(StreamClass, format) {
  EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-const VERSION = "2.11.0";
+const VERSION = "2.11.2";
 
 /*
  Copyright (c) 2025 Gildas Lormeau. All rights reserved.
@@ -9120,18 +9126,17 @@ function _make(isCompress, type, options = {}) {
 					}
 					heap.set(buffer.subarray(offset, offset + toRead), this.in);
 					const result = process(this.streamHandle, this.in, toRead, out, outBufferSize, 0);
+					// checked before the byte count is used, so a status code can never be read as one
+					const code = (result >> 24) & 0xff;
+					const signedCode = (code & 0x80) ? code - 256 : code;
+					if (signedCode < 0) {
+						throw new Error("process error:" + signedCode);
+					}
 					const prod = result & 0x00ffffff;
 					if (prod) {
 						scratch.set(heap.subarray(out, out + prod), 0);
 						controller.enqueue(scratch.slice(0, prod));
 					}
-					if (!isCompress) {
-						const code = (result >> 24) & 0xff;
-						const signedCode = (code & 0x80) ? code - 256 : code;
-						if (signedCode < 0) {
-							throw new Error("process error:" + signedCode);
-						}
-					}
 					const consumed = last_consumed(this.streamHandle);
 					if (consumed === 0 && prod === 0) {
 						break;
@@ -9151,14 +9156,12 @@ function _make(isCompress, type, options = {}) {
 				const scratch = this._scratch;
 				while (true) {
 					const result = process(this.streamHandle, 0, 0, out, outBufferSize, 4);
-					const produced = result & 0x00ffffff;
 					const code = (result >> 24) & 0xff;
-					if (!isCompress) {
-						const signedCode = (code & 0x80) ? code - 256 : code;
-						if (signedCode < 0) {
-							throw new Error("process error:" + signedCode);
-						}
+					const signedCode = (code & 0x80) ? code - 256 : code;
+					if (signedCode < 0) {
+						throw new Error("process error:" + signedCode);
 					}
+					const produced = result & 0x00ffffff;
 					if (produced) {
 						scratch.set(heap.subarray(out, out + produced), 0);
 						controller.enqueue(scratch.slice(0, produced));