Zip.js Files

What's Changed in v2.16.0

New features

• A fallback codec class passed as CompressionStreamFallback or DecompressionStreamFallback can declare two static flags, now documented on CompressionStreamLike and DecompressionStreamLike. supportedFormats lists the formats the class supports, e.g. ["deflate-raw", "gzip"], and the library reads it instead of probing a format by constructing the class. requiresModule, when true, says the class cannot be constructed before the module of the worker is ready, the WebAssembly module of zip.js or the module loaded by the init function passed to initWorker: the library then waits for that module, uses the native codec instead when the module fails to load, and opens a compression class as "gzip" to read the CRC-32 of the data from the trailer, so such a class must support that format

Performance

• With checkCrc32: true, the WebAssembly codec and the native DecompressionStream verify the CRC-32 while inflating, so the separate pass over the output on the JavaScript thread is gone for those two codecs. On the WebAssembly codec the check costs about 7 ms per 20 MB instead of 15, and reading a 20 MB text entry takes 53 ms instead of 62 ms on Node.js; on Node's DecompressionStream the pass was already overlapped by the threadpool and the gain is within the noise. Entries compressed with deflate64 or a registered codec, AES entries whose CRC-32 is not stored, and the pure-JavaScript zlib port keep the separate pass. The mechanism is the one the writer has used since 2.15.0: the raw deflate data is framed as gzip with a trailer holding the CRC-32 and size declared by the entry, which the inflater checks
• HttpReader with combineSizeEocd: true, the option, off by default, that fetches the last 64 KB of the archive with the request that reads its size, now serves the entry data lying in those bytes from that response. Reading an archive shorter than 64 KB costs that one request, where each entry used to issue a range request of its own, and in a larger archive an entry stored in its last 64 KB costs no extra request. With useXHR: true the reader already behaved that way

Bug fixes

• On a host whose DecompressionStream lacks "deflate-raw", Chromium 80 to 102 and Node.js 18 for instance, an entry with a corrupted CRC-32 read with checkCrc32: false was delivered as if it were valid, and an entry whose stored uncompressed size was wrong failed only after a 5 second watchdog. The gzip decoder of such a host checks the CRC-32 and size in the trailer it is given regardless, so the verification is free: a corrupted entry now fails with ERR_INVALID_CRC32 whatever checkCrc32 says, and a wrong size fails with ERR_INVALID_UNCOMPRESSED_SIZE as soon as the output has been read
• With useCompressionStream: false and a CompressionStreamFallback or DecompressionStreamFallback whose constructor throws, the entry now fails with that error. It used to be served silently by the gzip format of the native codec, so useCompressionStream: false was not honoured

Documentation

• BENCHMARKS.md states the cost of the CRC-32 check on read: about 7 ms per 20 MB on the WebAssembly codec, within the noise on Node's DecompressionStream, and about 15 ms on the pure-JavaScript zlib port, which keeps a separate pass

Tests and continuous integration

• New tests pin the gzip trailer on the inflate side, with the corrupted CRC-32 and size errors on the WebAssembly and native codecs and the raw route with the check off, the end of archive cache of HttpReader with the request counts of a small archive and of an entry in the cached tail, the propagation of a fallback codec failure, the CRC-32 and size verification on a host without "deflate-raw", and the formats such a host is asked for on the deflate and inflate sides
• The continuous integration runs on Ubuntu 26.04, and the reader stream release test allows 30 s per step instead of 5, a test timeout only, which the Firefox 102 lane of the native build exceeded under load in three of four runs

Full Changelog: https://github.com/gildas-lormeau/zip.js/compare/v2.15.0...v2.16.0

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com