Releases: jvilk/BrowserFS
v1.4.3
- Upgrades
buffer
version to 5.0.7. Fixes issue with cross-browser-contextArrayBuffer
instances, and fixes compatibility with browsers that lackArrayBuffer.isView()
. - Comprehensive and actionable error messages for file system configuration options. If you mess up a file system option, BrowserFS will spit out a useful and actionable error message now.
- Options object is optional for
Create()
methods when file system takes no options. Previously, the behavior was inconsistent. Now, callingCreate(cb)
is equivalent to callingCreate({}, cb)
.
v1.4.2
v1.4.1
v1.4.0
This should be the last minor version of BrowserFS in the 1.x series. Future releases in the 1.x series will be limited to bug fixes.
This version standardizes the way that users instantiate BrowserFS backends, provides a much more convenient method of configuring BrowserFS as a whole, and should be significantly easier to use for newcomers to the library.
This version also adds deprecation notices to a number of APIs that will be removed in 2.x in favor of these more convenient and standardized instantiation methods.
Here are the changes in this version:
- New convenience methods:
BrowserFS.configure(configObj, function(e) {})
: Configure BrowserFS with a single object. See the README for more information. This is the single best change to BrowserFS in this update!Create()
Methods: Every single file system has aCreate
function that accepts file system-specific options as an object and a callback. These are easy to promisify, but you don't even have to use these directly if you useBrowserFS.configure
!MountableFileSystem.Create()
: The new way of instantiating theMountableFileSystem
takes in a mount map:BrowserFS.FileSystem.MountableFileSystem.Create({ '/tmp': inMemory }, function(e, fs) {})
- Deprecated methods: Deprecates awkward initialization phases from file systems and constructors that require callbacks.
new BrowserFS.FileSystem.AsyncMirror(sync, async)
: UseBrowserFS.FileSystem.AsyncMirror.Create({ sync: sync, async: async }, function (e, fs) {})
instead.AsyncMirror.initialize()
: UseAsyncMirror.Create
, which handles initialization for you.new BrowserFS.FileSystem.Dropbox(client)
: UseBrowserFS.FileSystem.Dropbox.Create({client: client}, function (e, fs) {})
instead.new BrowserFS.FileSystem.HTML5FS(size, type)
: UseBrowserFS.FileSystem.HTML5FS.Create({ type: type, size: size }, function (e, fs) {})
instead.HTML5FS.allocate()
: UseHTML5FS.Create()
instead, which handles allocation for you.new BrowserFS.FileSystem.IndexedDB(storeName)
: UseBrowserFS.FileSystem.IndexedDB({ storeName: storeName }, function(e, fs) { })
instead.new BrowserFS.FileSystem.IsoFS(data, name)
: UseBrowserFS.FileSystem.IsoFS({ data: data, name: name}, function(e, fs) {})
instead.new BrowserFS.FileSystem.OverlayFS(writable, readable)
: UseBrowerFS.FileSystem.OverlayFS({ readable: readable, writable: writable }, function (e, fs) {})
instead.OverlayFS.initialize()
: UseOverlayFS.Create()
instead, which initializes OverlayFS for you!new BrowserFS.FileSystem.WorkerFS(worker)
: UseBrowserFS.FileSystem.WorkerFS({ worker: worker }, function (e, cb){})
instead.new BrowserFS.FileSystem.XmlHttpRequest(index, baseUrl)
: UseBrowserFS.FileSystem.XmlHttpRequest.Create({ index: index, baseUrl: baseUrl})
instead.XmlHttpRequest.FromUrl
: UseXmlHttpRequest.Create()
instead, which handles index URLs asynchronously.new BrowserFS.FileSystem.ZipFS(zipData, name)
: UseBrowserFS.FileSystem.ZipFS.Create({ zipData: zipData, name: name }, function (e, fs) {})
instead.ZipFS.computeIndex()
: UseZipFS.Create()
instead, which already computes indexes responsively.
v1.3.0
- Removes global
setImmediate
polyfill. It was not a proper polyfill, and avoided implementingclearImmediate
.- While never explicitly documented, others may have come to depend on this functionality, leading me to bump up the minor version.
- Proper API documentation
- There may be some rough edges, as we use typedoc (a TypeScript documentation generator) rather hackily.
- Deprecates using
new BrowserFS.FileSystem.XmlHttpRequest(url)
. This usage of the constructor invokedXmlHttpRequest
synchronously, which may freeze up your page. Instead, useBrowserFS.FileSystem.XmlHttpRequest.FromURL(url, function(e, fs) { /* FS is ready to go. */ }
.- This constructor will be removed in the next major version.
- I will likely revisit some other API design choices by then, too. (Like the constructors that take callbacks...)
Internal changes:
- Avoids using Buffer constructor. Uses
Buffer.from
/Buffer.alloc
instead. - Uses Yarn. Avoids weird issues/churn where minor NPM dependency version changes breaks CI builds / user builds.
v1.2.1
v1.2.0
Adds a new backend, and fixes a serious Emscripten bug.
- Adds IsoFS backend. Mount ISO files in the browser! Supports Joliet and Rock Ridge extensions to ISO9660 standard, as well as vanilla ISO9660 files.
- '.' and '..' now show up in Emscripten directory listings. Previously, these were missing from
readdir
calls, which is consistent with Node behavior and inconsistent with Emscripten behavior.
v1.1.0
Minor feature addition.
- ZipFS supports add-ons that add support for more decompression routines. The
browserfs-zipfs-extras
package adds support for UNREDUCE, UNSHRINK, and EXPLODE, but uses a difference license.
v1.0.0
- IE8 and IE9 are no longer supported. IE9 may still work, but is untested.
- Switches from
bfs-buffer
tofeross/Buffer
(https://github.com/feross/Buffer). Now, BrowserFS buffers properly handle array syntax, are instances ofUint8Array
, and should be faster than before. - Built with rollup, trimming 50KB off of the library. Rollup removes external library code that BrowserFS never referenced, and significantly reduces the amount of module-related boilerplate.
- (Webpack is still used to pull in some needed Node dependencies that cannot be rolled up just yet.)
v0.6.1
This is a minor, but recommended, bugfix release. This is the last version of BrowserFS to officially support IE9. IE8 may also work in this release, but it is untested.
- The
XmlHttpRequest
file system no longer throws an exception during certain synchronous downloads. Sometimes, a synchronous download would throw an exception because we would try to write a large value into a buffer as an 8-bit unsigned integer without disabling range checking. We now properly disable range checking, as we expect these values to be clamped to 8 bits. AsyncMirror
can now be used with synchronous file systems. Previously, we threw an exception whenever someone tried to mirror a synchronous file system. However, there are some cases where this is desired -- e.g., mirroring anXmlHttpRequest
file system to avoid synchronous XHR on the main thread.