Releases: jvilk/BrowserFS
Releases · jvilk/BrowserFS
v0.5.4
- process's EventEmitter-related functions now work. Previously,
bfs-process
did not expose these due to an oversight.- Due to a circular dependency issue,
process.std{out, in, err}
are initialized after a one-JavaScript-event delay. Your code can force their immediate initialization by callinginitializeTTD
.
- Due to a circular dependency issue,
- MountableFileSystem now appropriately sets the
path
property on errors. Previously, the paths pointed to paths in the mounted file systems, and did not include their mount point.
v0.5.3
v0.5.2
- Ability to have multiple fs modules on the same page. Now you can construct multiple independent
fs
modules.
var mainFsModule = BrowserFS.BFSRequire('fs');
var fsSecondary = new mainFsModule.FS();
fsSecondary.initialize(new BrowserFS.FileSystem.InMemory());
var fsTertiary = new mainFsModule.FS();
// etc.
- File descriptors are now numbers. Before, we gave applications
File
objects. Now, we give numbers.
v0.5.1
Minor bugfix release:
- Fixes localStorage backend with non-BFS buffer implementations. We normally use a custom binary string encoding to store data in localStorage, which takes advantage of the fact that most browsers allow you to store invalid UTF-16 in localStorage to pack 2X the data. We now fallback to base64 when binary string isn't available.
v0.5.0
This version brings about mostly internal changes:
- BrowserFS is now modular for Browserify projects. You can now easily use BrowserFS as the provider of the
fs
Node module. You do not have to use BrowserFS"sBuffer
,path
, andprocess
implementations. See the README for more information. - Improved compatibility with Node APIs. The
process
component is now a properEventEmitter
andpath
implements some previously-missing functions.fs
is still somewhat out-of-date (e.g. does not support streams). - Usable in Node. BrowserFS can be used from within Node, if you so choose. Note that there is currently no Node backend, so you can't mount Node's filesystem inside of BrowserFS's filesystem. I accept PRs, though, if an enterprising user feels like implementing this functionality!
v0.4.6
v0.4.5
v0.4.4
Version 0.4.4 brings a number of incremental improvements to BrowserFS:
- NPM package now exports TypeScript types!
- So when you
require('browserfs')
from TypeScript code, it'll be typechecked.
- So when you
- Improved SourceMaps that inline the TS source code.
- In deployment scenarios, you only need
.min.js
and.min.js.map
to trace back errors to the original TypeScript source.
- In deployment scenarios, you only need
Buffer
updated with Node v0.12 methods.SlowBuffer
is now defined in thebuffer
module.Buffer
now properly supports thenoAssert
option.- Fixes for Emscripten integration (from beta 0.4.2 release).
- Fixes for Dropbox backend:
- Now appropriately retries requests when rate limited or experiencing transient server / network errors.
- More accurate error code generation / error message generation.
- Avoids file transfers / directory reads when possible using Dropbox's
hash
andrev
fields, respectfully.- Note: You'll still never receive a stale version of either, since we check with Dropbox to ensure our cache is up-to-date. And it doesn't add latency, as this functionality is baked into the Dropbox REST API.
- Fixes for IE8
- Previously, we accidentally used
delete
as an identifier, which is a no-no. - NOTE: Actual IE8 not tested; I tested with IE10 in IE8 compatibility mode.
- Previously, we accidentally used
- Fixes for IE8 compatibility mode in IE10.
- Previously, we chose an incorrect buffer backend in this scenario, since IE10's compat mode erroneously defines an unusable
CanvasPixelArray
.
- Previously, we chose an incorrect buffer backend in this scenario, since IE10's compat mode erroneously defines an unusable
- General code cleanup.
v0.4.2
v0.4.1
Bugfix release:
- Fixed an issue where BrowserFS would use
Buffer
internally without explicitlyrequire
-ing it, causing issues if BrowserFS was used in a context whereBuffer
is not global. - Fixed an issue where IndexedDB filesystems would report being available in a private browsing setting that explicitly prevented the API's usage.