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