Skip to content

chore(deps): update npm (non-major) - #170

Merged
JonahMMay merged 5 commits into
mainfrom
renovate/npm-(non-major)
Aug 28, 2026
Merged

chore(deps): update npm (non-major)#170
JonahMMay merged 5 commits into
mainfrom
renovate/npm-(non-major)

Conversation

@renovate

@renovate renovate Bot commented Aug 10, 2026 •
edited
Loading

Copy link
Copy Markdown

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@babel/core@<7.29.6 (source) 7.29.6 → 7.29.7 age confidence
@​codemirror/view 6.43.6 → 6.43.9 age confidence
@tanstack/react-query (source) 5.101.4 → 5.102.8 age confidence
@tanstack/react-virtual (source) 3.14.8 → 3.14.10 age confidence
@testing-library/react 16.3.2 → 16.3.3 age confidence
@testing-library/user-event 14.6.1 → 14.6.6 age confidence
@types/react (source) 19.2.17 → 19.2.18 age confidence
@types/react-dom (source) 19.2.3 → 19.2.5 age confidence
@zip.js/zip.js (source) 2.8.34 → 2.8.60 age confidence
flatted@<=3.4.1 3.4.2 → 3.4.4 age confidence
hls.js 1.6.16 → 1.7.1 age confidence
jassub 2.5.11 → 2.5.14 age confidence
js-yaml@<4.3.1 4.3.1 → 4.3.2 age confidence
lucide-react (source) ^0.576.0 → ^0.577.0 age confidence
picomatch@>=4.0.0 <4.0.4 [4.0.4 → 4.0.7](https://renovatebot.com/diffs/npm/picomatch@>=4.0.0 <4.0.4/4.0.4/4.0.7) age confidence
pnpm (source) 10.32.1 → 10.34.5 age confidence
postcss@<8.5.23 (source) 8.5.23 → 8.5.26 age confidence
prettier-plugin-tailwindcss ^0.6.14 → ^0.8.0 age confidence
sonner (source) 2.0.7 → 2.0.8 age confidence
vite@>=6.0.0 <6.4.2 (source) [6.4.2 → 6.4.3](https://renovatebot.com/diffs/npm/vite@>=6.0.0 <6.4.2/6.4.2/6.4.3) age confidence
vitest (source) 4.1.10 → 4.1.11 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Release Notes

babel/babel (@​babel/core@<7.29.6)

v7.29.7

Compare Source

v7.29.7 (2026-05-25)

Re-release all packages with npm provenance attestations

TanStack/query (@​tanstack/react-query)

v5.102.8

Compare Source

Patch Changes

v5.102.7

Compare Source

Patch Changes

v5.102.6

Compare Source

Patch Changes

v5.102.5

Compare Source

Patch Changes

v5.102.4

Compare Source

Patch Changes

v5.102.3

Compare Source

Patch Changes

v5.102.2

Compare Source

Patch Changes

v5.102.1

Compare Source

Patch Changes

v5.102.0

Compare Source

Minor Changes
  • #​10668 e674826 - react-query: update usePrefetchQuery and usePrefetchInfiniteQuery to use queryClient.query and queryClient.infiniteQuery
Patch Changes
TanStack/virtual (@​tanstack/react-virtual)

v3.14.10

Compare Source

Patch Changes

v3.14.9

Compare Source

Patch Changes
testing-library/react-testing-library (@​testing-library/react)

v16.3.3

Compare Source

Bug Fixes
testing-library/user-event (@​testing-library/user-event)

v14.6.6

Compare Source

Bug Fixes
  • default pointer event pointerType to empty string instead of the string "undefined" (#​1325) (71a5475)

v14.6.5

Compare Source

Bug Fixes

v14.6.4

Compare Source

v14.6.3

Compare Source

gildas-lormeau/zip.js (@​zip.js/zip.js)

v2.8.60

Compare Source

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
Tests and continuous integration
  • New tests cover the registered codec snapshots, the codec constructor options transmitted to web workers, the VERSION constant, and the supported compression methods including the deferred resolution of codecURI codecs
  • The version bump now rebuilds the bundles so the published files embed the version, and the continuous integration verifies that the version constant agrees with the declared versions
Credits
  • Thanks to @​xqdoo00o for implementing the uncompressedSize option of the compression codecs (#​675)
  • Claude (Fable 5) contributed to every other change listed above

v2.8.59

Compare Source

What's Changed in v2.8.59

New features
  • New ZipReader#warnings property and warnings property on entries. They report non-fatal anomalies noticed while reading, as an array of { reason, filename? } objects deduplicated by reason. ZipReader#warnings is replaced on each getEntries() call and collects the archive-level observations: an unsorted central directory, an unknown "version needed to extract", the compressed patched data bit, a malformed extra field, unknown zip64 extensible data, and a wrapped 16-bit entry count. The entry-level warnings property is set by getData() and collects the local file header observations. The checks controlled by the strictness option deposit a warning with the same reason when a lower strictness tolerates what "strict" rejects: appended or prepended data, trailing central directory data, duplicate filenames, a mismatched zip64 end of central directory record, and local file header mismatches. The warnings only report bytes the parse already read, so enabling nothing costs no additional I/O. The reasons are exported as 14 WARNING_* constants
  • New isZipFile() function. It returns true if the data looks like a zip file, i.e. if ZipReader#getEntries called on the same data would locate the archive structure. It runs the same end-anchored search as ZipReader and verifies that a central directory record is stored where the end of central directory record points, without parsing the entries. The strictness and maxAppendedDataSize options control the tolerated appended data with the same semantics and defaults as ZipReader
  • New centralExtraField option of ZipWriter#add. It sets an extra field written only in the central directory record, complementing the localExtraField option which targets the local file header and the extraField option which targets both
Behavior changes
  • Leading and trailing whitespace in entry names is now preserved by ZipWriter#add instead of being silently trimmed. The zip specification does not restrict whitespace in filenames; note that Windows filesystems cannot represent a trailing space or dot in a name
  • Unclaimed bytes lying between the last central directory record and the end of central directory record are now detected, even when the declared central directory size matches the records. The "strict" strictness rejects such archives with the ERR_AMBIGUOUS_ARCHIVE error and the lower strictness levels deposit the "trailing central directory data" warning. These bytes were previously accepted silently at every strictness level, although the gap can hide records that other readers interpret, e.g. an unadvertised zip64 end of central directory record, and Info-ZIP and 7-Zip both flag such files. The check is skipped when the central directory is encrypted, because the plaintext is legitimately shorter than the stored data
Tests and continuous integration
  • A new test suite covers the warnings: each reason is triggered by byte surgery on a well-formed zip file and asserted both as a warning at the tolerant levels and as a rejection at the levels that make the corresponding check throw
  • New regression tests lock the preserved whitespace in entry names, the isZipFile() probe, the centralExtraField option, and the detection of unclaimed bytes before the end of central directory record
Credits
  • Claude (Fable 5) contributed to every change listed above

v2.8.58

Compare Source

What's Changed in v2.8.58

New features
  • New ZipWriter#appendZip method. It copies the entries of an existing zip file into the current zip. Unlike prependZip, it can be called at any position: after entries have been added, between add() calls, and repeatedly to merge several zip files. The central directory of the copied file is rebuilt and its entries are relocated to the positions they get in the output. prependZip is kept as a deprecated alias
  • New rawLastModDate option of ZipWriter#add. It sets the raw MS-DOS date and time of the entry directly, which passThrough copies of ZipCrypto entries need (see below)
  • New localDirectory.dataOffset property. It is the byte offset of the entry data, i.e. the entry offset plus the size of the local file header, of the filename and of the extra field. It can be used with Reader#createReadable to serve ranged requests into an entry stored without compression
  • New ERR_ZIP_CRYPTO_LAST_MOD_DATE error constant
Behavior changes
  • Errors of add() and appendZip() calls left un-awaited are not lost anymore. close() waits for the pending calls and throws the first unreported error, with all of them available in its entryErrors property. Throwing counts as reporting: catching the error and calling close() again finalizes the zip file without the failed entries. ZipWriterStream now aborts its writable when an entry fails, so the readable errors instead of hanging
  • An interrupted appendZip() copy now sets hasCorruptedEntries on the writer and keeps the offsets of the entries written after it consistent
  • The "version needed to extract" field is now 10 for entries stored without compression or encryption, instead of 20
  • Last modification dates before 1980 are now clamped to the MS-DOS epoch instead of underflowing the date field
  • The directory property of read entries is now derived from the trailing slash of the filename alone. A name ending with "/" is a folder even when the entry declares an uncompressed size
  • Unicode Path and Unicode Comment extra fields are now applied only when their version is 1, as required by section 4.6.8 of the zip specification
  • Reading an archive with a multiple of 65,536 entries and no zip64 record now returns all the entries. The 16-bit count of the end of central directory record wraps around; the reader detects the wrap by walking the central directory records past the declared count. The recovery is skipped when the strictness checks reject ambiguous archives
  • The unsafe* optimizations of the minifier were removed from the builds. Two of them shipped real miscompilations in the past, one of which stayed undetected for four years, and the size they saved was about 50 bytes per compressed bundle
Bug fixes
  • ZipCrypto entries copied with passThrough can now be read back with their password. The password verification byte of ZipCrypto depends on the raw date of the entry when a data descriptor is used, so a copy that regenerated the date or forced the descriptor failed with ERR_INVALID_PASSWORD. The dataDescriptor option is not forced anymore for pass-through ZipCrypto data, the new rawLastModDate option preserves the raw date, and the filesystem API forwards both when exporting, throwing the new ERR_ZIP_CRYPTO_LAST_MOD_DATE error if the date is overridden
  • The end of central directory records of split zip files now declare the number of central directory entries stored on the last disk, as required by section 4.4.21 of the zip specification, instead of the total. The count is 0 when the record starts on a fresh disk, which is how Info-ZIP fills the field. The check deciding whether the disk number of the record requires zip64 also accounts for the actual record and comment length when predicting a disk rollover near 65,535 disks
  • The spanning signature of split zip files is now written while holding the writer lock. A first entry written with bufferedWrite, or interleaved un-awaited add() calls, could fail on the locked stream or misplace the signature
  • Duplicate filenames are now detected before the entry waits for a worker slot. Two add() calls with the same filename made while the worker pool was saturated could both be accepted
Documentation
  • The usdz option states that its constraints apply to the entries written with add() only. The entries copied with appendZip keep the layout of the source zip file and are not checked
  • The ZipReader constructor states that a stream input is buffered entirely in memory, because reading a zip file requires random access, and points at custom Reader implementations for large seekable resources
  • WritableWriter#size states that a value set before the first write is used as the starting offset
  • useUnicodeFileNames states that disabling it only clears the language encoding flag and does not re-encode the filenames
  • passThrough documents the coupling between ZipCrypto and the last modification date
  • msDosCompatible documents how PKUNZIP handles folder entries
Tests and continuous integration
  • New PKZIP 1.10 and PKZIP 2.04g fixtures (attributes, comments, spanned archives) with tests reading the archives produced by the original tools
  • New regression tests lock the fixes above: the spanning signature position with concurrent and buffered writes, the per-disk entry counts of spanning central directories, including in the golden output, the ZipCrypto pass-through copies, the queued duplicate names, and the retryable close()
  • The Safari suite retries up to four times, the ZipCrypto tests are immune to date and wrong-password flakes, and the test fixtures are resolved independently of the working directory
  • The dead extra field handling of the appendZip entry rebuild was removed, making it explicit that copied entries carry their extra fields verbatim

v2.8.57

Compare Source

What's Changed in v2.8.57

New features
  • New ERR_UNSUPPORTED_UINT64 error constant
Behavior changes
  • Folders and empty stored entries are now written without a data descriptor. Their checksum and sizes are zero and known before the data is written, so bit 3 of the general purpose bit flag and the descriptor declared nothing, and other writers, e.g. Info-ZIP, leave them out. The local file header now carries the zeroed values directly, which shrinks every folder by the length of the descriptor. Those entries are also written directly instead of going through the buffered write path, since there is nothing to buffer. The descriptor is still written when the dataDescriptor option is set explicitly, and for encrypted entries
  • Reading an archive that declares a 64-bit value above Number.MAX_SAFE_INTEGER now throws the new ERR_UNSUPPORTED_UINT64 error. JavaScript numbers lose integer precision above 2^53 - 1, so a size or an offset that large was silently rounded to a nearby value and every computation derived from it was wrong. No valid archive is affected, such values describe contents beyond 8 PB
Bug fixes
  • The central directory records rebuilt by ZipWriter#prependZip now keep the zip64 layout of the source entries. The zip64 fields were selected again from the sizes of each entry, so a record whose source stored, e.g., only one of its sizes in the zip64 extra field was rebuilt with a different layout, and the zip64 field left in the raw extra field of the entry could be written twice. Prepending an archive and adding entries now produces the same bytes as writing all the entries directly
  • The InfoZip Unix extra field now stores both ids when only one of the uid and gid options is set, the missing one defaults to 0. The field used to declare the missing id with a length of 0, a layout Info-ZIP never writes and readers are not required to accept
Documentation
  • unixExtraFieldType now states that the filesystem API re-emits the uid and gid of imported entries as "infozip" whatever the field type found in the imported zip file, unless the option is set explicitly
Tests and continuous integration
  • The browser testing workflow was improved by @​danny0838: the browser driver is determined automatically, the download URL of old Chromium versions is computed from the version, and the runner works on Windows (#​674)
  • The web test runner now waits for the cleanup of the test frames before removing them and reports the in-flight tests when a run fails, and the old Chromium versions of the matrix are pinned to their snapshot position
  • The worker backpressure test now registers a codec that never signals backpressure and measures a deterministic bound on every runtime, instead of relying on the margin left by the native codec of each engine
  • New regression tests lock the fixes and changes above: the data descriptor rules for folders and empty stored entries, including the golden output, the zip64 layout of prepended entries, and the layout of the InfoZip Unix extra field when a single id is set
  • A new test locks that ZipWriter#remove returns false for an entry whose add() is still in flight and that the entry is written normally

v2.8.56

Compare Source

What's Changed in v2.8.56

Bug fixes
  • The compression method stored in the WinZip AES extra field is no longer truncated to its low byte. The field declares the actual compression method of an encrypted entry in a 16-bit slot, and it was written with a single byte store. An encrypted entry using a method above 255, which a codec registered with registerCodec can use, announced a different method, so readers selected the wrong codec after decrypting. Registered codecs exist since v2.8.37
  • Writing an entry with the usdz option now throws ERR_INVALID_EXTRAFIELD_DATA when the extra field could exceed 64KB once the alignment padding is added. The padding is computed after the length check and adds up to 67 bytes, so an extra field close to the limit wrapped the 16-bit length field and produced a corrupt entry
  • The central directory written by ZipWriter#prependZip now points at the prepended entries when the writer has an initial offset. The offsets were computed from the source archive alone, so an archive written with the offset option, or into a writer already holding data, declared offsets short by that initial offset and the prepended entries could not be read back. The two features could be combined since v2.7.71
  • The digital signature record is now written within a single segment of a split archive. It could start at the end of one segment and continue in the next, unlike every other record, because only the end of central directory record checked the remaining space before being written. The writer now closes the disk first for the signature record as well. Signing is available since v2.8.47
  • ZipReader#digitalSignature is now defined on a split archive whose central directory starts on an earlier disk than the end of central directory record. The reader looked for the record in the bytes read for the central directory, which stop at the declared directory length in that case, so the signature was never found. The record is now read from the file when it does not follow the directory in those bytes
  • ZipDirectoryEntry#getExportedSize now throws ERR_UNDETERMINED_SIZE when the predicted size depends on the order the entries are written. The zip64 fields of an entry depend on its offset, so when the entries total more than 4GB and the write order is not guaranteed, e.g. keepOrder set to false, two orders can produce two sizes. The detection walked the entries in enumeration order, so it missed layouts where only another order crosses the threshold, and the exported archive could differ from the prediction. The prediction is available since v2.8.52
  • ZipDirectoryEntry#getExportedSize now honors the offset option. The option shifts the offsets stored in the central directory, which select the zip64 fields, and the prediction computed them from zero. Predicting an export with offset at 4GB or above returned a size short by the zip64 records the export actually writes
Documentation
  • CodecDefinition#codecURI now states that bundlers and single-file builds, e.g. deno compile, cannot follow the dynamic import of the codec module, so the module must be included explicitly, with deno compile --include or the equivalent option of the bundler
Tests and continuous integration
  • Every fix above is locked by a regression test: an encrypted round trip with a registered method above 255, a usdz entry with an extra field near the 64KB limit, prependZip into a writer with an initial offset, a sweep of segment sizes checking the placement and the read back of the digital signature record on split archives, and size predictions with order-dependent zip64 layouts and with the offset option

v2.8.55

Compare Source

What's Changed in v2.8.55

New features
  • New ERR_UNDEFINED_COMPRESSION_METHOD error constant
Behavior changes

The two passThrough rules below change what the option accepts. Code that copies entries between archives by passing the compression method of the source entry, which is what the filesystem API does, is unaffected.

  • Writing an entry with the passThrough option now requires the compressionMethod option, and throws the new ERR_UNDEFINED_COMPRESSION_METHOD when it is missing. The data is copied as-is, so that option selects no codec, it declares how the data is already compressed and is written into the headers of the entry verbatim. It used to fall back to Deflate whatever the data was, so copying a stored entry without setting it produced an archive announcing Deflate over stored bytes, which no reader can decompress. Copying an entry read with ZipReader is a matter of passing its compressionMethod along. The entries with no content, e.g. the directories, ignore the option, as they ignore passThrough itself
  • The level option is now ignored for the entries written with passThrough. The data is never compressed, so the option describes nothing, and yet level set to 0 used to select the compression method written in the headers, stored instead of Deflate, and any level used to set the level bits of the general purpose bit flag. Set compressionMethod to declare how the data is compressed. level keeps applying to the other entries of the same archive, so exporting a filesystem with level set and passThrough set in the reader options still compresses the entries that were added to it and copies the entries that came from a zip file
  • The decryptCentralDirectory callback now receives the encrypted central directory alone. It used to be given the whole declared range of the directory, which also holds the digital signature record when the archive is signed, so the callback was handed bytes it cannot decrypt. The length is taken from the encryption header of the zip64 end of central directory record when it declares one, and falls back to the declared length of the directory. The callback has been given the whole range since it was introduced in v2.8.47
Bug fixes
  • Reading an archive whose central directory is encrypted no longer moves the directory somewhere else. The reader checks that the offset declared in the end of central directory record points at a central file header, and an encrypted directory carries no such signature, so the check failed and the offset was reconciled to another position. The offset is now trusted as well when the encryption header declares the size of the encrypted directory, and when the bytes at the offset look like an encrypted directory
  • The extensible data sector of the zip64 end of central directory record is now counted in the length of that record. The sector holds the encryption header of an encrypted central directory, and the reader subtracted the fixed length of the record only, so the computed end of the central directory sat past its real end by the length of the sector, and every offset derived from it was wrong
  • ZipReader#digitalSignature is now defined on an archive whose central directory is encrypted. The digital signature record follows the encrypted directory, so it is not part of what the decryption returns, and the reader looked for it in the decrypted bytes only
  • The local file headers masked by PKWARE strong encryption no longer make FileEntry#getData() throw ERR_AMBIGUOUS_ARCHIVE. When the central directory is encrypted, the local file header of an entry carries a placeholder filename and a zeroed checksum and sizes, and says so with bit 13 of its general purpose bit flag. The comparison against the central directory record that became the default in v2.8.53 rejected those archives. The filename, the checksum and the sizes are now left out of the comparison for those entries, the general purpose bit flag and the compression method are still compared
  • The published bundles no longer set the level bits of the general purpose bit flag on the entries written with the default compression level. index.min.js and the files of dist/ announced "super fast" on every Deflate entry whose level option was left unset, where the sources announce nothing. The minifier was configured with unsafe_comps, enabled in February 2022, which rewrites a comparison into its negation: !(0 > level) is true for an undefined level where level >= 0 is false. Those bits are advisory and no reader decompresses differently because of them, but an archive written by a bundle differed from the same archive written from the sources. The option is dropped from both minifier configurations, which costs 40 bytes on index.min.js
Documentation
  • ZipReader#digitalSignature now describes what the signature covers: the records of the central directory, read at ZipReader#directoryOffset, never including the digital signature record itself. zip.js does not verify signatures
  • ZipReader#directoryLength now warns that some writers, e.g. SecureZIP, count the digital signature record in the length they declare, so verifying the whole declared range can never succeed. Subtract 6 + digitalSignature.length from it when the record is stored inside the declared range
  • The passThrough option now describes how level and compressionMethod are treated, and states that the compression method is written into the headers as-is instead of selecting a codec
  • ZipReaderStream now states that it reads its input entirely into a Blob before it emits the first entry, since a zip file stores its central directory at the end. It is a convenience wrapper around ZipReader for stream sources, it does not extract the entries while the data is still arriving
Tests and continuous integration
  • New fixtures written by SecureZIP cover the strong encryption formats: AES-128, AES-192 and AES-256, stored and Deflate64 entries, an encrypted central directory, a certificate-based archive, a signed archive and an archive mixing encrypted and clear entries. They are read by the tests of decryptCentralDirectory and by the SecureZIP archive tests
  • A new fixture written by a third-party tool covers a zip64 entry whose sizes are stored in a data descriptor
  • The zip64 fixture of the HTTP test is rebuilt with real zip64 records, the previous one carried none although the test was named after them
  • The writer backpressure test now registers a codec that never signals backpressure on its writable side, instead of forcing the native one. It measured the invariant on Bun only, where the native CompressionStream behaved that way, and stopped measuring anything once Bun 1.4.0 fixed it. The registered codec keeps the test meaningful on every runtime
  • A new test locks the two passThrough rules above: the compression method is required, the level is ignored, and the level keeps applying to the other entries of the archive

v2.8.54

Compare Source

What's Changed in v2.8.54

Breaking changes
  • ZipWriter#prependZip() now reads an array of readers as the disks of a split zip file, which is what an array denotes everywhere else in the API, and accepts a SplitDataReader instance the same way. The disks are read in order and the entries are relocated to the positions they get in the output. An array used to be concatenated and read as a single archive, which produced wrong offsets for a real split zip file. If you were passing an array of byte ranges of one zip file, concatenate them yourself and pass a single reader
  • ZipEntry#moveTo() is removed. It was deprecated and undeclared in the TypeScript definitions, and was a one-line alias of ZipFS#move(), which is the method to use
  • The undeclared ZipFS#addData() and ZipDirectoryEntry#addData() methods are removed. They were internal, never documented and never declared. The typed addText(), addBlob(), addUint8Array(), addData64URI(), addHttpContent(), addReadable(), addFile(), addFileSystemEntry() and addFileSystemHandle() methods cover what they did
Security

Both fixes below are reachable from an untrusted zip file read with ZipReader. Upgrading is recommended for anyone reading archives they did not produce.

  • FileEntry#getData() now throws the new ERR_ENTRY_DATA_OUT_OF_BOUNDS when the declared data of an entry, i.e. its offset plus its compressed size, ends past the end of the zip file. Such an entry used to make getData() hang for ever, with no error and no CPU use, so nothing timed out and nothing showed up in a profile. Honestly truncated archives are affected as much as malformed ones. A read past the end of the source now ends the stream instead of stalling it, which also covers the entries the bounds check cannot detect in advance
  • The output of FileEntry#getData() is no longer allocated from the declared uncompressed size of the entry. The size was reserved before a byte was read, so a 131-byte archive declaring 3 GiB reserved 3 GiB. The allocation is clamped to what the compressed data can decode to, compressedSize * 1032 for a compressed entry and compressedSize for a stored one, 1032 being the maximum expansion ratio of Deflate. The clamp never binds on real data, a legitimate archive still preallocates exactly its uncompressed size
New features
  • ZipFS, ZipEntry, ZipFileEntry and ZipDirectoryEntry are now exported at the top level, and the fs namespace is deprecated. Replace new zip.fs.FS() with new zip.ZipFS(), and zip.fs.ZipFileEntry with zip.ZipFileEntry. zip.fs keeps working and the library emits no runtime warning, the deprecation is documentation only. ZipEntry is now a value as well, so entry instanceof zip.ZipEntry works. The three entry classes were already declared as top-level exports but existed at runtime under zip.fs.* only, so importing them type-checked and then failed. In TypeScript, the FS type is deprecated and kept as an alias of ZipFS, so let fs: FS keeps compiling
  • New ZipEntry#setOptions() method and ZipEntry#options property in the filesystem API. setOptions() merges the options into the ones the entry was added with, an option set to undefined being removed instead of stored, and they are applied when the zip file is exported. It is the way to set the options of an entry imported from a zip file, which has none until it is called. The options describing the data of an entry exported with passThrough, e.g. compressionMethod and uncompressedSize, are ignored, they are always the ones of the original entry, and so are directory and the progress callbacks
  • ZipWriter#prependZip() now writes a correct split zip file when the writer is a split zip file writer. The whole prepended archive used to be copied into the first disk, so every entry recorded an offset on the wrong disk. The data is copied disk by disk now, a disk is closed before an entry whose local file header would not fit in what is left of it, and each entry records the disk it starts on and its offset in that disk. The output also starts with the split zip file signature, unless the prepended zip file already carries one
  • TextWriter now decodes CP437. new TextWriter("cp437") used to return the data decoded as UTF-8, since the encoding was handed to FileReader#readAsText(), which falls back to UTF-8 for a label it does not know. It goes through the same decoder as the filenames and the comments now. It also decodes with TextDecoder instead of FileReader, which removes the last dependency on that class, missing from some worker scopes. The byte order mark is still removed, whichever branch decodes the data
  • The second argument of the codec stream constructors is now typed, by the exported CompressionStreamOptions and DecompressionStreamOptions interfaces. They document which members are set for which class, e.g. deflate64 only for the deflate implementations, and rawBitFlag, compressionMethod and uncompressedSize only for the codecs registered with registerCodec(). Configuration#CompressionStream, Configuration#DecompressionStream, their *Fallback and deprecated *Zlib forms and CodecDefinition are declared with them instead of the untyped TransformStreamLike. This only concerns you if you pass a custom stream implementation or call registerCodec()
  • Configuration#baseURI is now declared. It resolves the relative workerURI, wasmURI and codecURI values, and defaults to the URL of the module of zip.js
  • WritableWriter#size is now declared. zip.js sets it to 0 before the first write and keeps it updated, so a custom Writer can read how many bytes have been written so far, e.g. to compute the offset of a disk. It is declared on Writer, TextWriter, BlobWriter, SplitDataWriter and Uint8ArrayWriter as well
  • Members that existed and were not declared: HttpReader#url, TextWriter#encoding, BlobWriter#contentType, Data64URIWriter#contentType, EntryError#overlappingEntry and EntryError#reason. overlappingEntry is the only way to identify the other entry of the pair reported by ERR_OVERLAPPING_ENTRY, and reason describes the ambiguity reported by ERR_AMBIGUOUS_ARCHIVE
Behavior changes

The options listed first used to accept values of the wrong type and produced a wrong, empty or silently dropped result. They throw now. If your code passes the documented types, nothing changes.

  • lastModDate, lastAccessDate and creationDate must be Date instances and throw the new ERR_INVALID_DATE otherwise. An invalid Date used to be written as an entry carrying no timestamp at all. A timestamp expressed in milliseconds is the natural mistake and is rejected as well: pass new Date(file.lastModified), not file.lastModified
  • The comment option of an entry must be a string and throws the new ERR_INVALID_ENTRY_COMMENT_TYPE otherwise. A Uint8Array used to be coerced and its textual representation written into the archive. Decode the bytes to a string before passing them
  • The extraField option must be a Map, and throws the new ERR_INVALID_EXTRAFIELD otherwise. Its keys must be integers between 0 and 65535, and ERR_INVALID_EXTRAFIELD_TYPE now covers a non-integer or a negative key as well as a key above 65535. Its values must be Uint8Array instances, and throw the new ERR_INVALID_EXTRAFIELD_DATA_TYPE otherwise
  • The readerOptions option of ZipDirectoryEntry#export*(), ZipDirectoryEntry#getExportedSize() and ZipDirectoryEntry#exportFileSystemHandle() must be an object and throws the new ERR_INVALID_READER_OPTIONS otherwise. A value of anot

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (in timezone UTC)

  • Branch creation
    • Between 12:00 AM and 03:59 AM, only on Monday (* 0-3 * * 1)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot force-pushed the renovate/npm-(non-major) branch 6 times, most recently from 76ef826 to b4b28f6 Compare August 16, 2026 13:06
@renovate
renovate Bot force-pushed the renovate/npm-(non-major) branch 15 times, most recently from 43b620f to 84f8814 Compare August 23, 2026 23:01
@renovate
renovate Bot force-pushed the renovate/npm-(non-major) branch 7 times, most recently from 15fec19 to 47a448e Compare August 28, 2026 01:29
@renovate
renovate Bot force-pushed the renovate/npm-(non-major) branch from 7fc80c5 to c0f8651 Compare August 28, 2026 13:04
@cursoragent @JonahMMay
fix(web): restore vitest coverage deps dropped in silo sync
ffad302 
The #174 upstream merge replaced prairie's vitest coverage toolchain
with silo's eslint-only setup while CI still runs sharded coverage
tests. Re-add @vitest/coverage-v8, happy-dom, and the vite coverage
gate config so Renovate PR #170 web test jobs can run.

Co-authored-by: Jonah May <JonahMMay@users.noreply.github.com>
@renovate

renovate Bot commented Aug 28, 2026

Copy link
Copy Markdown
Author

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

cursoragent and others added 3 commits August 28, 2026 13:29
@cursoragent @JonahMMay
fix(web): use jsdom for vitest after silo sync
e47f2f2 
happy-dom does not support cqi container units or several DOM APIs that
CardOverlays, Layout, and VideoPlayer tests rely on. Keep coverage deps
from the prior fix but default to jsdom, matching silo's post-sync tests.

Co-authored-by: Jonah May <JonahMMay@users.noreply.github.com>
@cursoragent @JonahMMay
test(web): restore ensureStorageSchema coverage after silo sync
2ce43dd 
The upstream merge dropped schema-bump tests from storage.test.ts, leaving
branch coverage below CI's 95% gate. Re-add focused coverage for schema
versioning and localStorage failure paths.

Co-authored-by: Jonah May <JonahMMay@users.noreply.github.com>
@cursoragent @JonahMMay
test(web): isolate storage localStorage mocks between tests
b183f33 
The blocked-localStorage mock leaked into later tests in shard 3,
breaking round-trips values. Reinstall a fresh in-memory localStorage
in beforeEach so failure-path mocks cannot pollute siblings.

Co-authored-by: Jonah May <JonahMMay@users.noreply.github.com>
@JonahMMay
JonahMMay merged commit 3b0dcea into main Aug 28, 2026
14 checks passed
@JonahMMay
JonahMMay deleted the renovate/npm-(non-major) branch August 28, 2026 13:56
@JonahMMay JonahMMay mentioned this pull request Aug 28, 2026
Merged
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@JonahMMay @cursoragent