Skip to content

[stable33] build(deps-dev): bump @zip.js/zip.js from 2.8.59 to 2.9.0 - #64054

Open
dependabot[bot] wants to merge 1 commit into
stable33from
dependabot/npm_and_yarn/stable33/zip.js/zip.js-2.9.0
Open

[stable33] build(deps-dev): bump @zip.js/zip.js from 2.8.59 to 2.9.0#64054
dependabot[bot] wants to merge 1 commit into
stable33from
dependabot/npm_and_yarn/stable33/zip.js/zip.js-2.9.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 5, 2026

Copy link
Copy Markdown
Contributor

Bumps @zip.js/zip.js from 2.8.59 to 2.9.0.

Release notes

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

v2.9.0

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

v2.8.61

What's Changed in v2.8.61

Bug fixes

  • The keepOrder option now keeps the physical order of the entries, as its documentation states. Entries added concurrently were chained in the order in which they reached the internal write step instead of the order of the add() calls, so an entry whose reader initialized faster was written first. An entry added with level: 0 was always in that position, because storing skips the check of the deflate support that the other entries await, and a directory entry has no reader to initialize at all. The central directory order was already correct and the archives produced were valid, but the layout did not match the calls, and reading such an archive back deposited the "unsorted central directory" warning
  • ZipDirectoryEntry#getExportedSize() predicted a size smaller than the exported archive for a flat tree mixing files and directories exported with the usdz option. The directories were written before the files added before them, and the alignment padding of an entry depends on its position
  • ZipDirectoryEntry#getExportedSize() now reads the keepOrder option of each entry instead of the option passed to the export only. An entry added with keepOrder: false did not reach the check, and the returned size could differ from the exported archive. Such an export now throws ERR_UNDETERMINED_SIZE, as it already did when the option was passed to the export itself
  • ZipDirectoryEntry#getExportedSize() no longer throws ERR_UNDETERMINED_SIZE for an archive holding a single entry, or no entry at all, when the write order is not guaranteed. A single entry cannot be written in another order, so its size is determined, with the usdz option as well as past 4GB

Tests and continuous integration

  • New tests verify that the local file headers follow the order of the add() calls, whatever the speed of the readers and the compression level of the entries, and that an entry failing to initialize does not reorder the entries added after it
  • The test of the parallel ordered writes now verifies the order of the central directory and the physical order separately. It sorted the entries by offset before comparing them, so it could not detect a regression of the central directory order
  • New tests cover the size prediction of a flat tree mixing files and directories exported with the usdz option, of the entries carrying their own keepOrder option, and of the archives holding a single entry

v2.8.60

What's Changed in v2.8.60

New features

  • New VERSION constant exposing the version of the library at runtime (e.g. "2.8.60"). It matches the version declared in package.json; the continuous integration verifies the agreement
  • New getRegisteredCodecs() function. It returns the definitions of the codecs registered with registerCodec(), as snapshots that cannot alter the registry. The CompressionStream and DecompressionStream classes of a codec registered with codecURI appear in the result once its module has been imported
  • New getSupportedCompressionMethods() function. It returns the compression methods supported in the current environment and configuration: the built-in methods resolved against the compression streams available at the time of the call, followed by the registered codecs. Each entry reports the compression and decompression support separately, e.g. Deflate64 is read-only. The support of a codec registered with codecURI only is reported as undefined until its module is imported
  • Registered compression codecs now receive the size of the source data as CompressionStreamOptions#uncompressedSize when the reader has a known size. Codecs such as Zstandard can use it as the pledged source size and include the content size in the compressed frame (#675)

Bug fixes

  • The zip-fs-core build now exports the full core API. It previously exported only the filesystem classes, so configure(), registerCodec(), the reader and writer classes, and the constants were unreachable from this build

Documentation

  • The Reader class documents how to implement random access to files opened with the runtime APIs, with a Deno example
  • The offset and usdz options are documented as read when the ZipWriter is created and ignored when passed to ZipWriter#add, and the default value of offset read from Writer#size is documented

... (truncated)

Commits
  • 0663cb7 bump up version
  • c1965b6 keep the build output free of non-ascii characters
  • 44cdc01 warn when the prepended data holds a central directory
  • 668d997 bump up version
  • c026c5f predict the size of usdz archives holding one entry
  • 70d2d01 predict the size of a single entry past 4GB
  • 459b0c0 honor per-entry keepOrder in size estimation
  • bf200fe preserve add() call order in the physical entry layout
  • 02eb46e add release creation script
  • c701a4e keep in-progress ci runs on master
  • Additional commits viewable in compare view

Dependabot compatibility score

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)

Bumps [@zip.js/zip.js](https://github.com/gildas-lormeau/zip.js) from 2.8.59 to 2.9.0.
- [Release notes](https://github.com/gildas-lormeau/zip.js/releases)
- [Commits](gildas-lormeau/zip.js@v2.8.59...v2.9.0)

---
updated-dependencies:
- dependency-name: "@zip.js/zip.js"
  dependency-version: 2.9.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot requested review from a team as code owners September 5, 2026 02:36
@dependabot
dependabot Bot requested review from kristian-zendato, skjnldsv and susnux and removed request for a team September 5, 2026 02:36
@github-actions github-actions Bot changed the title build(deps-dev): bump @zip.js/zip.js from 2.8.59 to 2.9.0 [stable33] build(deps-dev): bump @zip.js/zip.js from 2.8.59 to 2.9.0 Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant