@zip.js/zip.js 2.11.3

on Node.js NPM

What's Changed in v2.11.3

Bug fixes

• Entries written with an unknown size, which is what ZipWriterStream and any ReadableStream source produce, no longer make the archive unreadable by the macOS extractors. The size of such an entry is only known once it has been written, so the writer has to pick the layout of the data descriptor before writing the first byte and commits to the ZIP64 one. The central directory is written last, when the real sizes are known, but it kept that layout: the 32-bit size fields stayed at 0xFFFFFFFF and the real sizes went to the ZIP64 extra field of the entry. Archive Utility and ditto only read that extra field when the archive carries a ZIP64 end of central directory record, which was not written for an archive small enough not to need one, so they read 0xFFFFFFFF as the size of the entry. A stored entry then failed with Couldn't read pkzip signature, a deflated one survived because the inflater ends on its own and never uses the size. unzip, 7-Zip and Windows Explorer read all of them. The central directory now drops the ZIP64 layout of an entry whose sizes turned out to fit in 32 bits, and an archive that does keep an entry in the ZIP64 layout now ends with a ZIP64 end of central directory record. An archive of one stored 1 MB entry written through ZipWriterStream is also 20 bytes smaller (#678)
• ZipDirectoryEntry#getExportedSize() no longer refuses to predict the size of a filesystem holding implicit directories. Those are the intermediate directories created by a name such as a/b/c.txt, they are not written to the archive, so they cannot change the order the entries are written in. The check that rejects a bufferedWrite export whose write order is not determined counted them as real directories, so it gave up on almost every filesystem built by addBlob() and friends. An explicit directory entry with children still throws ERR_UNDETERMINED_SIZE, as it must
• The lastModDate of the entry returned by ZipWriter#add() is now the date the archive actually stores. It reported the date rounded and clamped to the MS-DOS range even when the entry carries an extended timestamp or an NTFS timestamp, which hold the date at a higher resolution and without an upper bound. Reading the entry back gave a date the add() call had not reported

Error handling

• ZipWriter#add() throws ERR_INVALID_READER when its second argument is neither a Reader instance, a ReadableStream instance, nor an object exposing a readable property. Passing a Blob, a string or a Uint8Array directly, which has to be wrapped in BlobReader, TextReader or Uint8ArrayReader, wrote an empty entry with no error at all
• Writing a split zip file into a USDZ file throws ERR_UNSUPPORTED_SPLIT_USDZ. It used to write the split archive and silently break the 64-byte alignment USDZ requires, the offset of the breakage depending on where the disks happen to roll over. A USDZ file is a single package anyway, and a .zip/.z01/.z02 set is not one

Documentation

• The level option documents that an entry is stored instead of being compressed, rather than failing, when the environment provides no usable CompressionStream and the embedded implementation cannot be loaded. The compressionMethod of the entry returned by ZipWriter#add() is 0 in that case, which is how the fallback is detected
• The zip64 option documents why an entry of unknown size is written with ZIP64 in its local header, and that its central directory record drops ZIP64 when the actual sizes fit in 32 bits. The zip64 option of ZipWriter#close() documents that ZIP64 is also used when an entry is stored with ZIP64
• Two @see links in the types rendered with their label pasted inside the URL in the generated documentation

Tests and continuous integration

• New test asserting the layout of the size fields of an entry written with an unknown size, in the local header, the data descriptor and the central directory, for a stored entry, a deflated entry, an AES entry, a ZipCrypto entry and an entry with zip64 set to true
• New tests covering the rejection of a split writer in a USDZ file, the size prediction of a filesystem holding implicit directories, the date reported by ZipWriter#add() past the MS-DOS ceiling, and the readers ZipWriter#add() rejects

Credits

• Thanks to @dsine-de for reporting that an archive written with ZipWriterStream cannot be opened by the macOS archiver, and for the minimal repository that reproduced it (#678)