Zip.js Files

What's Changed in v2.13.1

Bug fixes

• The number of bytes a failed entry had already written is now counted once the aborted pipe has settled, so the entries added after it are recorded at the right offsets. It used to be read as soon as the failure was reported, while a write already in flight was still on its way to the writer, which left the count one chunk short and every following entry recorded before its real position. The archive was malformed and nothing threw, since the caller had observed the entry failure and ZipWriter#close() stays silent about it by design. Only the codec running in a worker was affected, which is the default wherever streams can be transferred
• The reason a caller aborts or cancels a stream with now reaches the caller back unchanged whether or not the codec ran in a worker. It used to be rebuilt from a structured clone when a worker was involved, so it was a different object, an error of a custom class arrived as a plain Error, and anything the caller had attached to it was dropped. DOMException kept its class, everything else did not

Documentation

• EntryError#outputSize documents that the reason a caller aborts with is annotated with it, so an error of your own carries an outputSize afterwards, and a value that cannot take a new property, e.g. a frozen error or a value that is not an object, is left alone

Tests

• The rejection reason tests assert the identity of the reason on both the reader and the writer paths, with and without a worker, instead of only checking that it was not replaced by an unrelated TypeError
• New check that the bytes a failed entry wrote are accounted for exactly, comparing what the writer accounts for against what the destination received. It only discriminates in a browser, where the streams are transferred to the worker; under Deno and Node.js every measurement is exact on both the fixed and the unfixed library

Full Changelog: https://github.com/gildas-lormeau/zip.js/compare/v2.13.0...v2.13.1