chore(deps): bump @zip.js/zip.js from 2.18.2 to 2.22.0 in the minor-deps-updates-main group

[dependabot]

Bumps the minor-deps-updates-main group with 1 update: @zip.js/zip.js.

Updates @zip.js/zip.js from 2.18.2 to 2.22.0

Release notes

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

v2.22.0

What's Changed in v2.22.0

appendZip()

• New readerOptions option: the options of the ZipReader which reads the zip file to copy. The zip file used to be read with the default options only, so a zip file the reader rejects by default could not be appended as-is. Set filenameValidation or strictness to copy the entries of a zip file holding unsafe or unusual filenames, filenameEncoding to decode the filenames the duplicate check and the filter option see, and password to let filter read the data of encrypted entries with getData(). The bytes of the entries are copied as-is whatever the options are. A value which is neither an object nor unset throws ERR_INVALID_READER_OPTIONS, now exported by the core builds as well
• The filter function receives a second argument: the entry of the current zip which has the same filename, as add() or a previous appendZip() call left it, or undefined when there is none. It is the way to apply a duplicate filename policy, since keeping both entries throws ERR_DUPLICATED_NAME: return !existingEntry to keep the entry of the current zip, call remove(existingEntry) and return true to replace it, or compare crc32, uncompressedSize or lastModDate to decide. A removed entry leaves its bytes in the output, as remove() always did, and a strict ZipReader reports them as prepended data. remove() now accepts the EntryMetaData returned by add() in its type declaration
• The zip file being copied is closed when filter throws, and the documentation of appendZip() now states that add() calls made while filter runs are written before the copied entries, while those made once the copy has started are written after it
• The entries passed to filter are not modified any more once the callback has returned: the copy used to rewrite their offset with the position in the output and to hang the fields of the rebuilt central directory on them
• A zip file whose own entries share a filename is rejected with ERR_DUPLICATED_NAME before anything is written, as before, and this is now documented: a ZipWriter holds one entry per filename, so the filter option is the way to keep one of them

Bug fixes

• new ZipReader(reader, null) reads the zip file with the default options instead of failing with a TypeError when the entries are read; a null options argument is treated as unset, like the other falsy values everywhere in the API

Removed

• The transferStreams configuration option is removed. It had been a no-op since v2.19.0, when the path transferring the streams to the web workers was removed: the data always crosses the worker boundary chunk by chunk. configure() ignores the key silently, so a call still passing it keeps working; TypeScript reports the key as unknown in WorkerConfiguration, delete it from the call

Tests

• A real byte overlap between two entries, stretched consistently in the local file header and the central directory record so that the default checkLocalDirectory check passes, is detected with checkOverlappingEntry whatever the order the entries are read in; the existing overlap fixtures overlapped only through a phantom data descriptor

Full Changelog: gildas-lormeau/zip.js@v2.21.0...v2.22.0

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com

v2.21.0

What's Changed in v2.21.0

Bug fixes

• An entry whose declared data extent (its offset plus its compressed size) ends past the central directory is rejected by getData() with ERR_ENTRY_DATA_OUT_OF_BOUNDS at every strictness level, with or without checkOverlappingEntry. Only the end of the file used to bound it, so a stored entry stretched over the directory returned the directory bytes as its content, and only checkCrc32 could catch it
• ZipWriter#appendZip() refuses to copy an entry listed with WARNING_MISSING_ZIP64_EXTRA_FIELD, i.e. whose central directory record holds a Zip64 sentinel with no Zip64 extra field resolving it: the method throws ERR_EXTRAFIELD_ZIP64_NOT_FOUND before writing anything, unless the filter option leaves the entry out. Such an entry used to be copied with zero sizes in the rebuilt central directory, or only its local file header through a filter, so the output entry was silently unreadable
• An entry whose central directory record lacks its Zip64 extra field is now parsed to the end of the record before the defect is reported, so its compression method, dates and other fields are listed with it. An entry whose local file header offset is the unresolved sentinel no longer makes the archive report "prepended data" from the offsets of the other entries
• The options passed to ZipReader#getEntries() and getEntriesGenerator() now reach the entries: entry.getData() reads them after its own options and before those of the ZipReader constructor, so a strictness, checkLocalDirectory, password or filenameEncoding given to getEntries() applies to the data as the type declarations described
• A central directory offset stored past the end of the file, e.g. in a damaged or truncated end of central directory record, is reconciled with the directory found before the record instead of failing with ERR_BAD_FORMAT, with the WARNING_MISMATCHED_CENTRAL_DIRECTORY_OFFSET reason deposited and the "strict" level rejecting the archive as before. The same reconciliation now covers a Zip64 end of central directory record stored at the wrong offset: the record is looked for right before its locator, then by its signature within the range the locator allows
• Before shifting the entries of an archive whose stored central directory offset does not match the directory found, the reader checks that the local file header of the first entry is found at the shifted position and not at the stored one; an archive whose stored offset is short of the directory while its entries sit at the shifted positions is diagnosed as WARNING_PREPENDED_DATA. The shift used to be decided on the direction of the mismatch alone, and a damaged offset could move the entries away from their local file headers
• An empty archive, i.e. one with no entry, behind prepended data is diagnosed with WARNING_PREPENDED_DATA and its prefix is extracted with extractPrependedData as for a non-empty one; it used to be read without a warning
• The CRC-32 checksum and the sizes of the data descriptor are compared with the central directory record when the descriptor is read, i.e. when checkOverlappingEntry is set, and a mismatch is reported as WARNING_MISMATCHED_LOCAL_FILE_HEADER_CRC32_OR_SIZES, an error or a warning depending on checkLocalDirectory. A local file header whose CRC-32 checksum and sizes are all zero without the data descriptor flag is tolerated, because some streaming writers leave these fields blank
• Reading an archive whose end of central directory record points into entry data holding the archive extra data signature no longer takes that data for an encrypted central directory: the record is only looked for at the start of the central directory, where the specification places it
• EntryMetaData#lastAccessDate and creationDate keep the values of the central directory record when it holds them; the values of the NTFS extra field of the local file header used to overwrite them once the data of the entry was read. When the central directory record holds none, e.g. with the extended timestamp field, whose central form stores the modification time only, the local file header stays their source

appendZip() with the filter option

• Each kept entry is copied from its local file header up to the exact end of its data or, when it has one, of its data descriptor, whose layout is read back from the zip file. The bytes outside the kept entries are dropped: a self-extracting stub, the data of entries removed earlier and the padding between entries, so a zip file aligned with the usdz option is not aligned any more once filtered. The copy used to stop at the next entry or at the central directory, so the data of a removed entry that followed a kept one was carried into the output
• Before anything is written, each kept entry is checked to start with a local file header and to end before the next entry or the central directory; otherwise the method throws ERR_LOCAL_FILE_HEADER_NOT_FOUND or ERR_OVERLAPPING_ENTRY and leaves the current zip unchanged. The same checks apply when the output is a split zip file, whose entries are copied one by one as well
• The general purpose bit flag of a copied entry is written as-is in the rebuilt central directory, including the bits zip.js never sets itself. A filtered copy into a split zip file writer now starts the first disk with the split zip file signature whatever the source starts with
• A copy that fails after some bytes were written marks the ZipWriter with hasCorruptedEntries and the error with corruptedEntry, as add() does; a failure before the first byte leaves the writer clean. Every filter call completes before any data is copied

... (truncated)

Commits

• 00efcb5 bump up version
• 1c34759 accept null reader options, close the source when the filter throws
• a3d8c1f pass the existing entry to the appendzip filter
• 3456c5b remove the dead transferstreams configuration key
• 2184671 test a real byte overlap under the local directory check
• a29703f add readerOptions to appendzip
• 4b6ec69 leave filter entries untouched in appendzip, document source duplicates
• 32385d3 bump up version
• 71979b5 update brace-expansion in the benchmarks lock file
• 9068cf0 probe the archive extra data record at the directory start, keep central dates
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually 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 <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml