v2.8.42

What's Changed in v2.8.42

New features

• New entry point @zip.js/zip.js/external referencing the web worker script and the WebAssembly module as external files instead of embedding them. Bundlers like webpack and Vite emit zip-web-worker.js and zip-module.wasm as separate assets, which removes approximately 45KB of embedded payloads from the main bundle. The worker also runs from a real file URL. This avoids blob: restrictions on pages and browser extensions with a strict Content Security Policy (cf. #669). Smaller compositions are also available: @zip.js/zip.js/lib/zip-fs-core-external.js excludes the MIME type table (approximately 23KB), and @zip.js/zip.js/lib/zip-core-external.js also excludes the filesystem API. The three compositions come with prebuilt ES module bundles in the /dist directory, which resolve the two asset files from their own directory
• New entry point @zip.js/zip.js/mime-types exposing getMimeType() with the full MIME type table, usable from any build
• zip.js now wraps raw deflate data in the gzip format and relies on CompressionStream("gzip")/DecompressionStream("gzip") when the "deflate-raw" format and the WebAssembly module are both unavailable. This makes reading and writing zip files work out of the box on Chromium 80 to 102 when a Content Security Policy blocks WebAssembly compilation, e.g. on extension pages (cf. #669), and lowers the minimum requirements of the "core" builds to Chrome 80, Node.js 18, and Deno 1.19. Reading AES-encrypted entries and Deflate64 entries is not supported with this fallback

Bug fixes

• A failure to load the WebAssembly module is now reported with an explicit "WASM module not loaded" error, with the original error as cause, e.g. the CSP error, instead of a TypeError thrown later by the codec (cf. #669)
• A failed load of the WebAssembly module is now retried on the next use instead of being cached for the whole session

Full Changelog: v2.8.41...v2.8.42