Skip to content

[stable32] build(deps-dev): bump @zip.js/zip.js from 2.8.60 to 2.9.0 - #64067

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

[stable32] build(deps-dev): bump @zip.js/zip.js from 2.8.60 to 2.9.0#64067
dependabot[bot] wants to merge 1 commit into
stable32from
dependabot/npm_and_yarn/stable32/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.60 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
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
  • See full diff 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.60 to 2.9.0.
- [Release notes](https://github.com/gildas-lormeau/zip.js/releases)
- [Commits](gildas-lormeau/zip.js@v2.8.60...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:37
@dependabot
dependabot Bot requested review from kristian-zendato, skjnldsv and susnux and removed request for a team September 5, 2026 02:37
@github-actions github-actions Bot changed the title build(deps-dev): bump @zip.js/zip.js from 2.8.60 to 2.9.0 [stable32] build(deps-dev): bump @zip.js/zip.js from 2.8.60 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