v2.16.0
- A fallback codec class passed as
CompressionStreamFallbackorDecompressionStreamFallbackcan declare two static flags, now documented onCompressionStreamLikeandDecompressionStreamLike.supportedFormatslists the formats the class supports, e.g.["deflate-raw", "gzip"], and the library reads it instead of probing a format by constructing the class.requiresModule, whentrue, says the class cannot be constructed before the module of the worker is ready, the WebAssembly module of zip.js or the module loaded by theinitfunction passed toinitWorker: the library then waits for that module, uses the native codec instead when the module fails to load, and opens a compression class as"gzip"to read the CRC-32 of the data from the trailer, so such a class must support that format
- With
checkCrc32: true, the WebAssembly codec and the nativeDecompressionStreamverify the CRC-32 while inflating, so the separate pass over the output on the JavaScript thread is gone for those two codecs. On the WebAssembly codec the check costs about 7 ms per 20 MB instead of 15, and reading a 20 MB text entry takes 53 ms instead of 62 ms on Node.js; on Node'sDecompressionStreamthe pass was already overlapped by the threadpool and the gain is within the noise. Entries compressed with deflate64 or a registered codec, AES entries whose CRC-32 is not stored, and the pure-JavaScript zlib port keep the separate pass. The mechanism is the one the writer has used since 2.15.0: the raw deflate data is framed as gzip with a trailer holding the CRC-32 and size declared by the entry, which the inflater checks HttpReaderwithcombineSizeEocd: true, the option, off by default, that fetches the last 64 KB of the archive with the request that reads its size, now serves the entry data lying in those bytes from that response. Reading an archive shorter than 64 KB costs that one request, where each entry used to issue a range request of its own, and in a larger archive an entry stored in its last 64 KB costs no extra request. WithuseXHR: truethe reader already behaved that way
- On a host whose
DecompressionStreamlacks"deflate-raw", Chromium 80 to 102 and Node.js 18 for instance, an entry with a corrupted CRC-32 read withcheckCrc32: falsewas delivered as if it were valid, and an entry whose stored uncompressed size was wrong failed only after a 5 second watchdog. The gzip decoder of such a host checks the CRC-32 and size in the trailer it is given regardless, so the verification is free: a corrupted entry now fails withERR_INVALID_CRC32whatevercheckCrc32says, and a wrong size fails withERR_INVALID_UNCOMPRESSED_SIZEas soon as the output has been read - With
useCompressionStream: falseand aCompressionStreamFallbackorDecompressionStreamFallbackwhose constructor throws, the entry now fails with that error. It used to be served silently by the gzip format of the native codec, souseCompressionStream: falsewas not honoured
BENCHMARKS.mdstates the cost of the CRC-32 check on read: about 7 ms per 20 MB on the WebAssembly codec, within the noise on Node'sDecompressionStream, and about 15 ms on the pure-JavaScript zlib port, which keeps a separate pass
- New tests pin the gzip trailer on the inflate side, with the corrupted CRC-32 and size errors on the WebAssembly and native codecs and the raw route with the check off, the end of archive cache of
HttpReaderwith the request counts of a small archive and of an entry in the cached tail, the propagation of a fallback codec failure, the CRC-32 and size verification on a host without"deflate-raw", and the formats such a host is asked for on the deflate and inflate sides - The continuous integration runs on Ubuntu 26.04, and the reader stream release test allows 30 s per step instead of 5, a test timeout only, which the Firefox 102 lane of the native build exceeded under load in three of four runs
Full Changelog: https://github.com/gildas-lormeau/zip.js/compare/v2.15.0...v2.16.0
Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com
v16.4.0-canary.37
- Preserve closed-parameter restrictions in client route prediction: #98889
- [test] Fix deployment tests that relied on implicit startup: #98935
- Turbopack: Add support for specifying additional roots: #98003
- Turbopack: Add symlinks and additional roots to NFT metadata: #98469
Huge thanks to @gnoff, @unstubbable, and @bgw for helping!
@formatjs/intl: 6.1.2
6.1.2 (2026-09-19)
- The following workspace dependencies were updated
- dependencies
- @formatjs/icu-messageformat-parser bumped to 3.5.20
- intl-messageformat bumped to 12.1.2
- dependencies
@formatjs/svelte-intl: 2.1.2
2.1.2 (2026-09-19)
- The following workspace dependencies were updated
- dependencies
- @formatjs/icu-messageformat-parser bumped to 3.5.20
- @formatjs/intl bumped to 6.1.2
- dependencies
babel-plugin-formatjs: 13.0.6
13.0.6 (2026-09-19)
- The following workspace dependencies were updated
- dependencies
- @formatjs/icu-messageformat-parser bumped to 3.5.20
- @formatjs/ts-transformer bumped to 4.4.22
- dependencies
vue-intl: 8.1.2
8.1.2 (2026-09-19)
- The following workspace dependencies were updated
- dependencies
- @formatjs/icu-messageformat-parser bumped to 3.5.20
- @formatjs/intl bumped to 6.1.2
- dependencies
@formatjs/ts-transformer: 4.4.22
4.4.22 (2026-09-19)
- The following workspace dependencies were updated
- dependencies
- @formatjs/icu-messageformat-parser bumped to 3.5.20
- dependencies
react-intl: 12.1.2
12.1.2 (2026-09-19)
- The following workspace dependencies were updated
- dependencies
- @formatjs/icu-messageformat-parser bumped to 3.5.20
- @formatjs/intl bumped to 6.1.2
- intl-messageformat bumped to 12.1.2
- dependencies
eslint-plugin-formatjs: 8.0.5
8.0.5 (2026-09-19)
- The following workspace dependencies were updated
- dependencies
- @formatjs/icu-messageformat-parser bumped to 3.5.20
- @formatjs/ts-transformer bumped to 4.4.22
- dependencies
formatjs_cli: 1.7.4
1.7.4 (2026-09-19)
- macOS Apple Silicon:
formatjs_cli-darwin-arm64 - Linux ARM64:
formatjs_cli-linux-arm64 - Linux x86_64:
formatjs_cli-linux-x64 - Windows x64:
formatjs_cli-win32-x64.exe
# macOS (Apple Silicon)
curl -LO https://github.com/formatjs/formatjs/releases/download/formatjs_cli_v1.7.4/formatjs_cli-darwin-arm64
chmod +x formatjs_cli-darwin-arm64
sudo mv formatjs_cli-darwin-arm64 /usr/local/bin/formatjs
# Linux
curl -LO https://github.com/formatjs/formatjs/releases/download/formatjs_cli_v1.7.4/formatjs_cli-linux-x64
chmod +x formatjs_cli-linux-x64
sudo mv formatjs_cli-linux-x64 /usr/local/bin/formatjs
# Linux ARM64
curl -LO https://github.com/formatjs/formatjs/releases/download/formatjs_cli_v1.7.4/formatjs_cli-linux-arm64
chmod +x formatjs_cli-linux-arm64
sudo mv formatjs_cli-linux-arm64 /usr/local/bin/formatjs
# Windows x64 (PowerShell)
curl.exe -LO https://github.com/formatjs/formatjs/releases/download/formatjs_cli_v1.7.4/formatjs_cli-win32-x64.exe
Verify the checksums:
curl -LO https://github.com/formatjs/formatjs/releases/download/formatjs_cli_v1.7.4/checksums.txt
shasum -a 256 -c checksums.txt