v2.8.51

What's Changed in v2.8.51

New features

• getChildren() returns the children of a directory as an array, and all its descendants when the recursive option is set to true. It is available on ZipDirectoryEntry and FS instances. The descendants are ordered level by level, like the result of readdir(path, { recursive: true }) in Node.js, which is also the order in which the entries are written by the export*() methods. Unlike the entries property of FS, the array excludes the root directory, leaves no empty slot for removed entries, and can start from any directory. It is a snapshot taken when the method is called, so the tree can be modified while the array is being iterated

Behavior changes

• The export*() methods of the filesystem API now write the entries in the same order whatever the value of the bufferedWrite option. Setting it to false used to write each branch of the tree entirely before moving to the next one, whereas the default writes the entries level by level, so an archive exported with bufferedWrite set to false does not have the same entry order as in the previous versions. Only the order changes: the entries, their content and their metadata are identical, and a directory entry still precedes the entries it contains

Compatibility improvements

• exportFileSystemHandle() called with concurrent set to true now reports the failure that stopped the export on browsers which do not support the reason argument of AbortController#abort(), e.g. Firefox 79 and Chromium 87. zip.js used to recognize the cancellation of the sibling entries by the reason it had passed to abort(). These browsers discard that reason and report a plain AbortError instead, so the cancellation was reported as the cause of the failure and the original error was demoted into entryErrors. The cancellation is now tracked by zip.js itself and never read back from the platform (see #669)
• exportFileSystemHandle() now rejects with an error instead of rejecting with undefined when the export is aborted through the signal option on these browsers. The reason passed to AbortController#abort() is discarded by the platform and cannot be recovered, so a DOMException named AbortError is thrown in its place. Its message is exposed as the new ERR_ABORTED constant. Testing error.name == "AbortError" now identifies an aborted export on every supported platform, whereas these browsers used to report a plain Error when the export was aborted before it started and an AbortError when it was aborted while an entry was streaming

Documentation

• The API documentation of exportFileSystemHandle() now states that an entry flagged as a symbolic link is written as a regular file whose content is the path of the link target, since the File System Access API cannot create symbolic links

Tests

• The test verifying that the abort reason of the caller is forwarded is now skipped on browsers without support for AbortSignal#reason instead of being reported as a failure. It moved to its own file and covers aborting before the export as well as aborting while an entry is streaming

Credits

• @danny0838 reported the failure on Firefox 79 and Chromium 87 and ran the test suite on these browsers

Full Changelog: v2.8.50...v2.8.51