v53.3.5
Published @platejs/core@53.3.5.
a102cd5by @github-actions[bot] – Updatedslate.
Published @platejs/test-utils@53.3.5.
- Updated
@platejs/core,@platejs/slate.
- Updated
@platejs/core,@platejs/slate,@platejs/utils.
Thanks to everyone who contributed to this release:
@NoiceHax
Full changelog: v53.3.4...v53.3.5
v2.8.51
getChildren()returns the children of a directory as an array, and all its descendants when therecursiveoption is set totrue. It is available onZipDirectoryEntryandFSinstances. The descendants are ordered level by level, like the result ofreaddir(path, { recursive: true })in Node.js, which is also the order in which the entries are written by theexport*()methods. Unlike theentriesproperty ofFS, 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
- The
export*()methods of the filesystem API now write the entries in the same order whatever the value of thebufferedWriteoption. Setting it tofalseused 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 withbufferedWriteset tofalsedoes 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
exportFileSystemHandle()called withconcurrentset totruenow reports the failure that stopped the export on browsers which do not support thereasonargument ofAbortController#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 toabort(). These browsers discard that reason and report a plainAbortErrorinstead, so the cancellation was reported as the cause of the failure and the original error was demoted intoentryErrors. 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 withundefinedwhen the export is aborted through thesignaloption on these browsers. The reason passed toAbortController#abort()is discarded by the platform and cannot be recovered, so aDOMExceptionnamedAbortErroris thrown in its place. Its message is exposed as the newERR_ABORTEDconstant. Testingerror.name == "AbortError"now identifies an aborted export on every supported platform, whereas these browsers used to report a plainErrorwhen the export was aborted before it started and anAbortErrorwhen it was aborted while an entry was streaming
- 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
- The test verifying that the abort reason of the caller is forwarded is now skipped on browsers without support for
AbortSignal#reasoninstead 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
- @danny0838 reported the failure on Firefox 79 and Chromium 87 and ran the test suite on these browsers
Full Changelog: https://github.com/gildas-lormeau/zip.js/compare/v2.8.50...v2.8.51