[stable34] build(deps-dev): bump @zip.js/zip.js from 2.11.2 to 2.11.4

[dependabot]

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

Release notes

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

v2.11.4

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

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)

Commits

• e49b0d4 source the chunk test from a portable readable and drain it
• 69cc8e0 assert the abort reason only where the engine exposes it
• 425bcc9 bump up version
• 7554347 honor an already aborted signal and enrich reader stream chunks
• 8ab2d78 bump up version
• 80593b6 drop the dead this arm from the globals banner
• 86a68f3 fix size prediction, reported dates and the invalid reader error
• bc1b06f reject split output in usdz files
• 148d542 drop zip64 from the central directory when the sizes fit
• b3131da measure the level frontier on both runtimes, not just deno
• 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)