@zip.js/zip.js 2.8.61

on Node.js NPM

What's Changed in v2.8.61

Bug fixes

• The keepOrder option now keeps the physical order of the entries, as its documentation states. Entries added concurrently were chained in the order in which they reached the internal write step instead of the order of the add() calls, so an entry whose reader initialized faster was written first. An entry added with level: 0 was always in that position, because storing skips the check of the deflate support that the other entries await, and a directory entry has no reader to initialize at all. The central directory order was already correct and the archives produced were valid, but the layout did not match the calls, and reading such an archive back deposited the "unsorted central directory" warning
• ZipDirectoryEntry#getExportedSize() predicted a size smaller than the exported archive for a flat tree mixing files and directories exported with the usdz option. The directories were written before the files added before them, and the alignment padding of an entry depends on its position
• ZipDirectoryEntry#getExportedSize() now reads the keepOrder option of each entry instead of the option passed to the export only. An entry added with keepOrder: false did not reach the check, and the returned size could differ from the exported archive. Such an export now throws ERR_UNDETERMINED_SIZE, as it already did when the option was passed to the export itself
• ZipDirectoryEntry#getExportedSize() no longer throws ERR_UNDETERMINED_SIZE for an archive holding a single entry, or no entry at all, when the write order is not guaranteed. A single entry cannot be written in another order, so its size is determined, with the usdz option as well as past 4GB

Tests and continuous integration

• New tests verify that the local file headers follow the order of the add() calls, whatever the speed of the readers and the compression level of the entries, and that an entry failing to initialize does not reorder the entries added after it
• The test of the parallel ordered writes now verifies the order of the central directory and the physical order separately. It sorted the entries by offset before comparing them, so it could not detect a regression of the central directory order
• New tests cover the size prediction of a flat tree mixing files and directories exported with the usdz option, of the entries carrying their own keepOrder option, and of the archives holding a single entry