Update dependency @zip.js/zip.js to v2.12.0

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@zip.js/zip.js (source)	2.8.61 → 2.12.0

---

Release Notes

gildas-lormeau/zip.js (@​zip.js/zip.js)

v2.12.0

Compare Source

What's Changed in v2.12.0

Breaking changes

• The language encoding flag (general purpose bit 11) is now set only when the encoded filename or the encoded comment of an entry holds a byte outside printable ASCII, where it used to be set on every entry. Nearly every archive zip.js writes therefore differs from v2.11.4 byte for byte. Nothing is decoded differently, printable ASCII being spelled identically in UTF-8 and in Code Page 437, and it is how every other writer decides the flag. Control characters are excluded deliberately: the Code Page 437 table maps 0x01 to 0x1f and 0x7f to the IBM graphic characters rather than to the control characters themselves, so a name or a comment holding one of them keeps the flag and keeps round-tripping
• EntryMetaData#filenameUTF8 and EntryMetaData#commentUTF8 returned by ZipWriter#add() now report the flag that was actually written, where they always reported true. They agree with the values read back from the archive, which the previous behaviour contradicted for every entry whose name is printable ASCII
• HttpReader now throws an ERR_HTTP_STATUS error for any status outside 2xx, where it accepted everything below 400. A 304 answered by a caching proxy to a conditional request was read as a successful empty response, and the archive failed later with an unrelated end of central directory error
• The checkPasswordOnly option combined with passThrough set to true now verifies the password. It reported every password as valid, wrong ones included, and streamed the whole entry instead of stopping after the first block: passing the encryption stage through left nothing able to raise the sentinel that means "the password is correct"
• ZipDirectoryEntryImportOptions#passThrough and the passThrough option of ZipDirectoryEntryExportOptions#readerOptions are typed boolean instead of boolean | "compressed". The filesystem API has always refused "compressed" at runtime, the types now say so and code passing it stops compiling

New features

• New passThrough value, "compressed", which passes the compression stage through and still runs the encryption stage. It is what re-encrypting an entry without recompressing it needs: reading with it decrypts and does not inflate, writing with it encrypts and does not deflate. passThrough is a depth rather than a pair of switches, and encryption is the outer stage
• New entry option on ZipWriter#add(), which takes the entry read from another archive and derives the ten or so values a copy needs from it. Copying an entry by forwarding the obvious subset used to produce silent corruption, an encrypted entry landing marked encrypted=false over untouched ciphertext. The oracle the option is built on is byte identity: an archive copied entry by entry with { passThrough: true, entry } is the archive it was read from
• New checkLocalFilename option, which selects whether the filename of the local header is compared, independently of whether a difference throws. The two axes were conflated: strictness: "strict" compared the filename and rejected, everything else did neither, so a mismatched filename could never be reported as a warning. { checkLocalFilename: true, checkLocalDirectory: false } now reports it on EntryMetaData#warnings
• ZipDirectoryEntry#exportZip() accepts a ZipWriter instance, the symmetric counterpart of ZipDirectoryEntry#importZip() accepting a ZipReader. The entries are added to that writer and the archive is left open, so the caller closes it, can add entries of its own before or after, can export several trees into one archive, and can read ZipWriter#warnings
• New ZipWriter#warnings channel, reporting the adjustments the writer makes silently: an entry stored because no deflate implementation is reachable, a date clamped to the MS-DOS range with no extra field left to carry the original value. Each reason is deposited once, with the filename of the first entry it applied to
• ZipReader and ZipWriter implement Symbol.asyncDispose, so await using finalizes the archive on scope exit
• New outputSize property on the errors thrown by the codecs, holding the number of bytes that reached the writer before the failure. It is what a caller salvaging an archive after a mid-entry failure needs to know
• ZipWriter#add() accepts null as the reader of an entry with no content
• Every user-visible error message is now exported as a constant, ERR_ABORTED included, and an audit in the test suite keeps it that way across the fourteen builds
• configure() checks the type of baseURI, workerURI and wasmURI, which used to fail much later and quietly

Bug fixes

• The codecs of a reader stream are now released on demand and on cancel, instead of being held until the whole archive was read
• A failure raised on the main thread while a codec task runs over the worker message protocol now carries outputSize, so the writer advances by the bytes that really reached it. It did not, and the central directory of an archive salvaged after such a failure was written short of the real positions, by 655360 bytes in the measured case
• Terminating the workers no longer leaves the WebAssembly module torn down while an operation that reloaded it believes it is loaded, which silently substituted the native gzip path for the rest of the process
• preventClose no longer makes FileEntry#arrayBuffer() and ZipReaderStream hang forever. Both build their writable internally, exactly like the Writer instances the option is documented to ignore
• A copy made with the entry option now derives the deflate level bits, the language encoding flag and the unix extra field type of the source entry. It dropped the level bits, cleared bit 11 on an ASCII-named source that carried it, and rewrote a 0x7855 record as a 0x7875 one
• The refusal to change the last modification date of a ZipCrypto entry no longer fires under passThrough: "compressed", where the entry is encrypted again or not encrypted at all and the date is free to change
• ZipDirectoryEntry#exportFileSystemHandle() now refuses the "compressed" value of passThrough spelled at the top level, as it already did through readerOptions. It wrote the raw deflated bytes into the extracted files instead
• ZipDirectoryEntry#getExportedSize() is async, so its option validation errors reject instead of throwing synchronously out of a method declared to return a promise
• The ERR_INVALID_UNCOMPRESSED_SIZE error now carries outputSize, which the most common corruption shape did not set
• An entry written with passThrough and no crc32 to declare is refused instead of being written with a wrong one, and AE-2 is written when encrypting passthrough content
• The local header and the central directory now agree on the extended timestamp record

Documentation

• The extendedTimestamp remark no longer claims that EPUB allows an extra field on its mimetype entry. OCF states that there must not be one, which is what pins the byte offset of application/epub+zip so a reader can sniff the format without parsing the archive, and epubcheck reports it as an error. ODF and EPUB need the same pair of options
• Twelve other claims corrected against what the code does, among them: the precedence of the values the entry option reads, which beat the options of the ZipWriter rather than being defaults against them; the condition under which WARNING_CLAMPED_LAST_MODIFICATION_DATE appears; the combinations under which LocalDirectory#rawFilename is defined; the status codes ERR_HTTP_STATUS covers; what ERR_INVALID_URI validates; and the determinability of getExportedSize() for names holding a slash, obsolete since implicit directories were exempted
• The options of ZipWriter#close() are documented as belonging to the caller closing the archive when a ZipWriter is passed to exportZip(), globalComment and signCentralDirectory included
• The entry option points at the branch it selects for an encrypted source: it supplies encrypted, so copying such an entry with passThrough set to true writes the ciphertext as-is and keeps the password it was encrypted with, while a password in scope encrypts the other entries only. Re-keying is what "compressed" is for

Tests and continuous integration

• The whole lint script runs in CI, deno lint included, and the fidelity harness runs in test-ci
• New fixture and test covering a Windows Explorer zip64 archive: a Deflate64 entry too large for 32 bits, in an archive carrying no zip64 end of central directory, with the two headers sentinelling different size fields
• New tests for the passthrough stages, the copy entry option, the async dispose path, the reader stream release, the writer warnings and the filesystem export into a ZipWriter
• The type tests are checked to be registered in a tsconfig, and the API export surface is audited across every build

Full Changelog: gildas-lormeau/zip.js@v2.11.4...v2.12.0

v2.11.4

Compare Source

What's Changed in v2.11.4

Bug fixes

• An AbortSignal already aborted when ZipWriter#add() or Entry#getData() is called now rejects the call. The signal was only handed to pipeTo(), which ignores it on the engines below its support floor, i.e. the oldest browsers the test matrix covers: the whole entry was then written and there was nothing left to abort. Both methods now check the signal before starting, and reject with signal.reason when it is set, so the error is unchanged on the engines that already honored it, or with an AbortError whose message is ERR_ABORTED otherwise, signal.reason not existing before Chrome 98. A pre-aborted add() also rejects before the temporary stream of a buffered entry is created, so nothing is allocated to dispose
• The chunks of a ZipReaderStream now expose the properties deposited on an entry while its data is read, i.e. EntryMetaData#warnings and EntryMetaData#localDirectory. The chunk was built from a copy of the entry taken before the read started, so those two were permanently absent from it, and the warnings channel added in v2.8.x was unreachable from ZipReaderStream although the types promise it. The chunk now shares them with the entry, so they are readable on it once its readable property has been consumed
• BlobReader no longer fails with sourceBlob.stream is not a function when its source is a Blob-like object exposing only size, slice and arrayBuffer. It reads with stream() when the source has it and falls back to the slice()/arrayBuffer() path otherwise, which the reader already implemented for the engines whose Blob#slice is unreliable

Documentation

• The signal option of the reader and of the writer documents that a signal already aborted rejects the call, and with which error

Tests and continuous integration

• New test covering a signal already aborted when add() and getData() are called, with and without a reason, registered without the pipeToSignal feature gate so that it runs on the engines the fix is for
• New test covering a BlobReader over a source without stream()
• The warnings test asserts that a ZipReaderStream chunk carries the local directory and the warnings of its entry
• The temporary stream test no longer uses a pre-aborted signal to reach its error path, which no longer creates a temporary stream, and covers a failing Reader instead; a second case pins that a pre-aborted add() creates none

v2.11.3

Compare Source

What's Changed in v2.11.3

Bug fixes

• Entries written with an unknown size, which is what ZipWriterStream and any ReadableStream source produce, no longer make the archive unreadable by the macOS extractors. The size of such an entry is only known once it has been written, so the writer has to pick the layout of the data descriptor before writing the first byte and commits to the ZIP64 one. The central directory is written last, when the real sizes are known, but it kept that layout: the 32-bit size fields stayed at 0xFFFFFFFF and the real sizes went to the ZIP64 extra field of the entry. Archive Utility and ditto only read that extra field when the archive carries a ZIP64 end of central directory record, which was not written for an archive small enough not to need one, so they read 0xFFFFFFFF as the size of the entry. A stored entry then failed with Couldn't read pkzip signature, a deflated one survived because the inflater ends on its own and never uses the size. unzip, 7-Zip and Windows Explorer read all of them. The central directory now drops the ZIP64 layout of an entry whose sizes turned out to fit in 32 bits, and an archive that does keep an entry in the ZIP64 layout now ends with a ZIP64 end of central directory record. An archive of one stored 1 MB entry written through ZipWriterStream is also 20 bytes smaller (#​678)
• ZipDirectoryEntry#getExportedSize() no longer refuses to predict the size of a filesystem holding implicit directories. Those are the intermediate directories created by a name such as a/b/c.txt, they are not written to the archive, so they cannot change the order the entries are written in. The check that rejects a bufferedWrite export whose write order is not determined counted them as real directories, so it gave up on almost every filesystem built by addBlob() and friends. An explicit directory entry with children still throws ERR_UNDETERMINED_SIZE, as it must
• The lastModDate of the entry returned by ZipWriter#add() is now the date the archive actually stores. It reported the date rounded and clamped to the MS-DOS range even when the entry carries an extended timestamp or an NTFS timestamp, which hold the date at a higher resolution and without an upper bound. Reading the entry back gave a date the add() call had not reported

Error handling

• ZipWriter#add() throws ERR_INVALID_READER when its second argument is neither a Reader instance, a ReadableStream instance, nor an object exposing a readable property. Passing a Blob, a string or a Uint8Array directly, which has to be wrapped in BlobReader, TextReader or Uint8ArrayReader, wrote an empty entry with no error at all
• Writing a split zip file into a USDZ file throws ERR_UNSUPPORTED_SPLIT_USDZ. It used to write the split archive and silently break the 64-byte alignment USDZ requires, the offset of the breakage depending on where the disks happen to roll over. A USDZ file is a single package anyway, and a .zip/.z01/.z02 set is not one

Documentation

• The level option documents that an entry is stored instead of being compressed, rather than failing, when the environment provides no usable CompressionStream and the embedded implementation cannot be loaded. The compressionMethod of the entry returned by ZipWriter#add() is 0 in that case, which is how the fallback is detected
• The zip64 option documents why an entry of unknown size is written with ZIP64 in its local header, and that its central directory record drops ZIP64 when the actual sizes fit in 32 bits. The zip64 option of ZipWriter#close() documents that ZIP64 is also used when an entry is stored with ZIP64
• Two @see links in the types rendered with their label pasted inside the URL in the generated documentation

Tests and continuous integration

• New test asserting the layout of the size fields of an entry written with an unknown size, in the local header, the data descriptor and the central directory, for a stored entry, a deflated entry, an AES entry, a ZipCrypto entry and an entry with zip64 set to true
• New tests covering the rejection of a split writer in a USDZ file, the size prediction of a filesystem holding implicit directories, the date reported by ZipWriter#add() past the MS-DOS ceiling, and the readers ZipWriter#add() rejects

Credits

• Thanks to @​dsine-de for reporting that an archive written with ZipWriterStream cannot be opened by the macOS archiver, and for the minimal repository that reproduced it (#​678)

v2.11.2

Compare Source

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

Compare Source

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 1677721 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

Compare Source

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

• 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

Credits

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

v2.10.0

Compare Source

What's Changed in v2.10.0

New features

• New duplicates option on the import*() methods of the filesystem API, set to "throw", "keep-first" or "keep-last". A zip file stores a flat list of filenames while the filesystem API indexes the entries by path, so two entries can claim the same node of the tree: they can hold the same filename, hold filenames differing only by the path components ignored when building the tree such as "a/b.txt" and "./a/b.txt", or one can be a file and the other a directory holding it such as "a" and "a/b.txt". The three cases are now governed by one option instead of aborting the import in every case. The default stays "throw", an archive holding the same name twice being also the shape making an extractor and a scanner disagree on the file they see. "keep-last" is the behavior of most zip tools, verified against Info-ZIP, 7-Zip, libarchive, ditto, Python zipfile, fflate and JSZip
• The name passed to an add*() method of the filesystem API is now split into path components, like the filename of an imported entry already was. addText("a/b.txt", text) adds "b.txt" to the "a" directory and creates that directory when it does not exist, instead of adding one entry whose name holds a "/". The directories created that way are implicit, they are not written when the tree is exported, so the exported zip file is unchanged. rename() splits the name the same way and moves the entry accordingly
• New ERR_DUPLICATE_IMPORTED_ENTRY and ERR_INVALID_DUPLICATES errors, and new ZipDirectoryEntryImportOptions type. ERR_DUPLICATE_IMPORTED_ENTRY replaces ERR_ENTRY_EXISTS when an import is refused, the former reading as an error made by the caller while the caller only passed a zip file

Bug fixes

• A failed import no longer modifies the filesystem. The entries created before the error are removed, and the content the ZipFS instance held before the import is restored instead of being discarded before the first entry is read
• The replace*() methods of the filesystem API now update the size of the entry, which kept describing the content held before the call. The archive was written correctly, only getExportedSize() was affected: replacing 1 byte of text with 5000 bytes predicted 127 bytes for an export of 5126. replaceReadable() reports an undetermined size, like addReadable() does, instead of returning a prediction it cannot make. The five methods also clear the pass-through state of an entry imported with the passThrough option, the bytes copied verbatim being gone
• ZipFS#find() no longer throws a TypeError when a component of the path it is given is a file entry rather than a directory
• Renaming an entry to the name it already has is no longer refused as a collision with itself

Documentation

• New Hello world with the filesystem API example in the README. The filesystem API needs a single import, infers the Reader and the Writer from the type of the data, and reaches an entry from its name, which is what the five other examples never showed
• The encoding limitations of the filename options are now documented
• The conditions making getExportedSize() unable to predict a size mention that a name holding "/" builds a nested tree

Tests and continuous integration

• New tests covering the duplicate filename policies, the rollback of a failed import, the path components built from a name, and the size of an entry whose content is replaced
• The size prediction tests cover the names holding "/", the two duplicate policies and the entries whose imported content is replaced
• The CP437 table is now checked by a test instead of at runtime, and the characters it decodes are written as characters in that test

v2.9.0

Compare Source

What's Changed in v2.9.0

New features

• New WARNING_PREPENDED_CENTRAL_DIRECTORY warning, deposited when the data found before the archive holds a central directory of its own. It tells apart the two shapes producing the WARNING_PREPENDED_DATA warning, a self-extracting stub carrying the archive and several archives concatenated, which were indistinguishable until now. The distinction matters because the readers disagree on the archive to read in the second case: zip.js, Info-ZIP and Python read the last one, 7-Zip reads the first one. The new warning costs no additional read, it reports what the search of the end of central directory already saw

Bug fixes

• The CP437 table decoding the names of the entries not marked as UTF-8 is now written with escape sequences, and the whole build output is free of non-ASCII characters. The table was made of literal characters, so a build parsed as something else than UTF-8, e.g. inlined in a page declaring another charset, read a table longer than 256 entries. The check comparing its length to 256 then fell back to TextDecoder, which decodes UTF-8, so every byte past ASCII became a replacement character instead of the expected name. The minified files grow by 438 bytes and shrink by 177 bytes once compressed

Tests and continuous integration

• The build now fails when the output holds a non-ASCII character
• New test covering the archives concatenated with each other, verifying that the entries of the last archive are the ones reported and that a prefix holding no central directory does not deposit the new warning

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.