build(deps-dev): bump @zip.js/zip.js from 2.9.0 to 2.11.2

[dependabot]

Bumps @zip.js/zip.js from 2.9.0 to 2.11.2.

Release notes

Sourced from @​zip.js/zip.js's releases.

v2.11.2

What's Changed in v2.11.2

Bug fixes

• Concurrent calls to ZipWriter#add() compress concurrently again. Since v2.10.0 every entry of a batch took the path that writes directly into the zip file, and each of them then waited for the previous entry to be written, so the batch was compressed one entry at a time. The writer now records that choice in the same step that makes it, so the first entry is written directly into the file and the others are buffered, as before. Measured on 8 entries of 8 MB with the native CompressionStream, the same batch of concurrent add() calls goes from 2211 ms to 607 ms. The archive is unchanged, only the scheduling was wrong
• A Reader that declares its size and always returns the number of bytes it is asked for no longer makes ZipWriter#add() read it forever. The writer did not pass that size when it built the readable stream, so the stream ended only when the reader returned an empty array. The stream also advances by the number of bytes actually returned instead of by the requested chunk size, so a reader that returns a short chunk in the middle of the data no longer skips the rest of the chunk

Documentation

• The keepOrder option no longer states that concurrent calls to ZipWriter#add() compress one entry at a time and need bufferedWrite to overlap. That described the bug above, not the intended behavior

Benchmarks

• The benchmarks report the size each library produced next to every time, and a new bench-codecs.js compares the codecs alone, sorted by output size. A compression level is not a unit shared between libraries, so a table matched on level reads a difference in compression ratio as a difference in speed

v2.11.1

What's Changed in v2.11.1

Bug fixes

• A failure inside the WebAssembly codec is now reported as the error it is instead of surfacing as RangeError: offset is out of bounds. The deflate_process, inflate_process and inflate9_process functions pack the number of bytes produced in the low 24 bits and the zlib status code in the top byte, but their two error paths returned a bare negative code, read as 16777214 bytes produced and copied out of the module heap into a 64KB buffer. Reaching it takes the codec running out of its fixed 16MB heap, which needs useCompressionStream and useWebWorkers both set to false, so that every entry shares one module instance, and maxWorkers raised above the number of streams the heap holds, 42 measured when compressing at level 6
• The compress direction of the WebAssembly codec now checks the status code the codec returns, which only the decompress direction did. A failed deflate() reports no byte produced and no byte consumed, which the loop reads as the end of the data, so the rest of the entry was dropped without an error. The status is also checked before the number of bytes produced is used, so a status code can no longer be read as a byte count whatever the codec returns

Tests and continuous integration

• New test asserting that the vendored WebAssembly module packs its error codes the way the codec expects. The module is vendored as a binary, so nothing else in the suite would notice it being re-vendored stale

v2.11.0

What's Changed in v2.11.0

Breaking changes

• 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

Bug fixes

• 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

Performance

• 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)

Documentation

• 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

Tests and continuous integration

... (truncated)

Commits

• 3b81b8f bump up version
• f9e8a48 compare codecs by output size in the benchmarks
• 894fc57 document that concurrent add still compresses concurrently
• 68533fe fix concurrent add serialization and unbounded custom reader streams
• 12e92cf bump up version
• 6280cda skip the codec encoding test on builds without the wasm
• 7bbaa55 check the vendored codec packs its error codes
• 245ce73 report codec errors instead of decoding them as a byte count
• 7dc3bcf leave the bun runners out of the workflow
• 6898d67 run the node, deno and bun suites in the workflow
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)