[stable33] chore(deps-dev): bump @zip.js/zip.js from 2.18.2 to 2.23.0

[dependabot]

Bumps @zip.js/zip.js from 2.18.2 to 2.23.0.

Release notes

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

v2.23.0

What's Changed in v2.23.0

New features

• Add the filter option to the import*() methods of ZipFS and ZipDirectoryEntry: the function receives each entry read from the zip file and returns true (or a promise resolving to true) to import it. It can read the data of the entry to decide, and the entries left out never reach the duplicates policy
• Add the filter option to the export*() methods and to getExportedSize(): the function receives each ZipEntry of the tree and returns true to export it. Leaving out a directory leaves out its subtree, the entries left out are not read and are not counted by onprogress and onentryprogress
• Add the filter option to exportFileSystemHandle(), with the same semantics as the zip exports
• Add the filter option to addFileSystemHandle() and addFileSystemEntry(): the function receives each handle found and its path, so a directory like node_modules or hidden files can be left out without walking them

Full Changelog: gildas-lormeau/zip.js@v2.22.1...v2.23.0

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

v2.22.1

What's Changed in v2.22.1

Bug fixes

• A zip file written behind a prefix which was removed together with its whole first entry, like a self-extracting page whose first entry is the face shown by the host, is read again: the entries are shifted to their real positions and their data can be read. Since v2.21.0, the shift was decided on the first central directory record only, and a first record whose local file header lies in the removed bytes proves nothing, so the entries kept their stored offsets and getData() failed with ERR_LOCAL_FILE_HEADER_NOT_FOUND, whatever the strictness option. The reader now checks the following records until one settles the question, and keeps the protection against a damaged end of central directory record whose local file headers are right
• An entry which lies before the start of the zip file after such a shift is no longer reported as WARNING_UNSORTED_CENTRAL_DIRECTORY

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

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

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

... (truncated)

Commits

• a6ba503 bump up version
• d1735b8 add a filter option to the file system handle methods
• 0a5dddd add a filter option to the filesystem imports and exports
• ee23dab bump up version
• 6694ef2 confirm a central directory shift on the following records
• 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
• 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)