build(deps-dev): bump @zip.js/zip.js from 2.8.34 to 2.8.50

[dependabot]

Bumps @zip.js/zip.js from 2.8.34 to 2.8.50.

Release notes

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

v2.8.50

What's Changed in v2.8.50

New features

• New filenameValidation option in ZipReader and getEntries(). It rejects entry names that do not map safely to a file path. It accepts "strict", "balanced" and "tolerant", and defaults to the value of the strictness option. Rejected names throw the new ERR_UNSAFE_FILENAME error, which carries the offending name in its filename property
• New normalizeFilename option in ZipReader and getEntries(). It is called with the decoded name of each entry and its result replaces that name. It runs after decoding and before validation, so repairing a name is enough to make it pass filenameValidation. Returning undefined keeps the decoded name. The filesystem API inherits the option from ZipReaderConstructorOptions
• The decodeText and encodeText options now receive the type of the text they handle, "filename" or "comment", as their last argument. Hooks declaring fewer parameters keep working
• exportFileSystemHandle() now reports what happened when an export fails. The new entryName property of EntryError holds the name of the entry that failed, relative to the exported entry. The new exportedEntryNames property lists the files that were completely written before the failure. Every other file of the export is either missing or empty, so this is the only way to tell a file the export completed from one it created but never filled
• exportFileSystemHandle() called with concurrent set to true now collects every failure instead of reporting only the first one. The other failures are listed in the new entryErrors property of EntryError. Failures raised deeper in the tree are flattened into that list
• New ERR_INVALID_LEVEL, ERR_INVALID_PASSWORD_TYPE, ERR_INVALID_STRICTNESS, ERR_INVALID_FILENAME_VALIDATION and ERR_INVALID_MAX_APPENDED_DATA_SIZE error constants

Breaking changes

• Entry names containing a .. path component, or starting with /, with a drive letter like C:, or with \\, are now rejected when reading an archive. They throw ERR_UNSAFE_FILENAME. Set filenameValidation to "tolerant" to restore the previous behavior. This default was verified against a corpus of 572 archives holding 257,333 entries. None of them was rejected, so the new default costs nothing on real archives. A backslash is never treated as a path separator. It is legal on UNIX file systems, and it also occurs as the trail byte of double-byte filenames in Shift-JIS, Big5 and GBK, where converting it would corrupt the name
• The strictness option set to "strict" now also rejects empty and . path components, e.g. a//b.txt and ./cur.txt
• Invalid option values now throw instead of falling back silently to a default. A level outside the integers 0 to 9 throws ERR_INVALID_LEVEL, and used to disable compression entirely when it was negative or not a number. A password that is not a string, or a rawPassword that is not a Uint8Array, throws ERR_INVALID_PASSWORD_TYPE. A value of another type used to produce an unencrypted archive, and a rawPassword passed as a string used to produce an archive that its equivalent password cannot open. An unknown strictness or filenameValidation throws instead of behaving as "balanced". An invalid maxAppendedDataSize throws instead of being accepted. A non-integer encryptionStrength, uid, gid or unixMode is now rejected by the guard whose message already announced it. Values meaning "no password", i.e. undefined, null, an empty string and an empty Uint8Array, keep working as before. Numeric options also keep accepting the strings that represent them, e.g. level set to "9", because form controls, query strings and environment variables all yield strings
• The filesystem API now ignores empty and . path components when importing an archive. Names such as a//b.txt and ./cur.txt no longer create entries with an empty name or named .
• When reading an entry fails, the writable of the writer is now aborted with the error instead of being closed. A custom writer used to observe a successful close although the data was truncated

Bug fixes

• Errors raised by addFileSystemHandle() and exportFileSystemHandle() are now rethrown unmodified instead of being wrapped. Their message is comparable to the exported ERR_* constants again, and their entryName property identifies the handle or the entry that failed
• exportFileSystemHandle() called with concurrent set to true now cancels the entries that have not started yet when an entry fails, instead of letting the rest of the export run to completion

Build and packaging

• Web worker support is now tree-shakable. The web worker backend was moved to a separate module which registers itself when imported. Custom builds that do not import it no longer include the web worker plumbing and run codecs inline. The standard entry points import it, so the published builds are unaffected
• The most frequently used globals are destructured in the intro of the bundles, which reduces the size of the minified builds

Full Changelog: gildas-lormeau/zip.js@v2.8.49...v2.8.50

v2.8.49

What's Changed in v2.8.49

Compatibility improvements

• The embedded JavaScript deflate engine is now compiled with an ES2019 target. It no longer contains nullish coalescing operators, which require Chromium 80. As a result, the WebAssembly and "native" builds now work down to Chromium 76 instead of 80 (see #669). The compatibility table on https://gildas-lormeau.github.io/zip.js/ has been updated accordingly
• Fixed a regression introduced in v2.8.18: when the worker script passed via workerURI could not be started as a module worker, zip.js fell back silently to inline workers instead of retrying with a classic worker. Browsers without module worker support, e.g. Chromium 76 to 79, now load external worker scripts again
• Codecs registered with registerCodec() and a codecURI now run inline transparently when the web worker cannot import the codec module, e.g. on browsers which do not support import() in workers like Chromium 76 to 79 and Firefox 102 to 113. Setting useWebWorkers to false is no longer needed on these browsers

These changes were verified by running the test suite on real Chromium 76, 79 and 80 builds. Known limitation on Chromium 76 to 79: aborting operations in progress has no effect because these versions ignore the signal option of pipeTo(). The data read or written remains correct.

Full Changelog: gildas-lormeau/zip.js@v2.8.48...v2.8.49

v2.8.48

Bug fixes

• Fixed reading and writing data when the global stream classes are polyfilled, e.g. with web-streams-polyfill on Firefox 79. Reading a zip file from a stream, Entry#arrayBuffer(), createBlobTempStream() and the filesystem API could fail or hang because zip.js consumed streams internally with the native Response constructor or ReadableStream#pipeTo(), which do not accept polyfilled streams. With the polyfill loaded, the whole test suite now passes in an environment without TransformStream. Thanks to @​danny0838 for running the test suite on older browsers (#669)
• Fixed the generation of temporary file names in createOPFSTempStream() and createSyncAccessHandleTempStream() when crypto.randomUUID is unavailable, e.g. in Chrome 67 to 91 or Safari 14.1 to 15.3

... (truncated)

Commits

• b2803a5 bump up version
• a2646a2 update markdown doc
• affdaca reject NaN explicitly and restore the production build snapshot
• 67c8cf5 accept numeric strings for numeric options
• c1c4916 reject invalid option values instead of silently falling back to defaults
• 0fcdedd tell encodeText and decodeText whether they handle a filename or a comment
• e69b1e9 add normalizeFilename option to repair entry names before validation
• a34e978 reject unsafe entry filenames and ignore redundant path components
• 66b266d report the files written before a failed export
• 15a3db8 cancel remaining entries when a concurrent export fails
• 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 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)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
prose-reader-demo	Ready	Preview	Aug 18, 2026 1:08am
prose-reader-front	Ready	Preview	Aug 18, 2026 1:08am

[dependabot]

Superseded by #315.