@zip.js/zip.js 2.11.0 on Node.js NPM

What's Changed in v2.11.0

ERR_INVALID_CRC32 and ERR_INVALID_AUTHENTICATION_CODE now hold distinct values, "Invalid CRC32" and "Invalid authentication code". Both were aliases of ERR_INVALID_SIGNATURE since v2.8.44, added as aliases so the two errors could be told apart later without breaking the code comparing them at the time. ERR_INVALID_SIGNATURE is removed, the term naming a CRC-32 check and an AES authentication code, neither of which is a signature. Code comparing an error message to it must now compare to the constant naming the check that failed
The externalFileAttribute and internalFileAttribute names are removed, from the entry properties and from the writer options. They were renamed to externalFileAttributes and internalFileAttributes in January 2025 and kept as aliases since. The other names deprecated in the 2.8 releases are kept. The minified files shrink by 354 bytes

Deflate64 entries are no longer refused when a match at least as long as the 64KB output buffer of the WebAssembly codec starts on its boundary. The codec then fills a whole buffer without consuming any input, which was read as the end of the data: the rest of the chunk was dropped, and the entry failed with a Z_BUF_ERROR at the default chunk size, or with an invalid uncompressed size when the chunks were small enough for the loss to pass unnoticed until the end. Only Deflate64 allows such a match, its maximum length being 65538 bytes against the 258 of Deflate, and 7-Zip does not produce one, its Deflate64 encoder capping the matches at 257 bytes. The JavaScript codec was unaffected
The JavaScript codec no longer corrupts the data when a match wraps around the end of the sliding window and ends inside it. The bytes were then copied from the output buffer instead of the window, which needs more than 32KB already decompressed and a match straddling the wrapping point. deflate and gzip reported the corruption as an invalid checksum, deflate-raw returned the expected number of bytes with a few of them wrong. The entries of a zip file are read as deflate-raw and checkCrc32 is not set by default, so the wrong bytes were returned with no error at all. The codec is the one the index-native and legacy builds use, including to read Deflate64

The WebAssembly codec is now built from Chromium's fork of zlib, which reads 20% faster and writes 6 to 8% faster. The compressed output is unchanged, byte for byte, at every level. The module grows by 1592 bytes. The codec is used when the CompressionStream API is unavailable or turned off with the useCompressionStream option, and always when reading Deflate64 (#677)

The keepOrder option no longer claims that setting it to true improves the use of web workers, which is the opposite of what it does. Keeping the order writes the entries one after another, so concurrent calls to add() compress one entry at a time. The remark now says so and points to bufferedWrite, which restores the concurrency while still keeping the order

New test covering a Deflate64 match starting on the boundary of the output buffer, in both codecs
New test covering a match wrapping around the end of the sliding window of the JavaScript codec, in both codecs
The test pinning the attribute names now covers the precedence of the entry options over the writer options instead of the removed aliases

Thanks to @xqdoo00o for reporting that Chromium's fork of zlib compresses faster than the one the WebAssembly codec was built from (#677)