search

jvilk / BrowserFS

BrowserFS is an in-browser filesystem that emulates the Node JS filesystem API and supports storing and retrieving files from various backends.
Other
3.07k stars 218 forks source link

npm/browserify support #107

Closed wjordan closed 9 years ago

wjordan commented 9 years ago

I'd love to use this project as a modular dependency within a npm+browserify-based project, instead of having to add it through an explicit script tag and manipulate the BrowserFS variable on the global browser scope. I see the project already has a package.json, but it looks like it's only using npm right now to include external dependencies in its own build process, not to make the library's modules available as a package. What do you think would be needed to expose the necessary functionality through an npm package published on the public registry?

timdream commented 9 years ago

This is probably achievable by modifying the the outro in the build process and ask BrowserFS to be exported at module.exports if such object exists. I can offer help on this with @jvilk's blessing.

Alternatively, can/should the above manual step be automated with umd instead? Specifically, grunt-umd.

jvilk commented 9 years ago

@timdream I'd be more than grateful for the assistance! I'm currently working on the compilation issue you reported in #106.

jvilk commented 9 years ago

Regarding automating the process with grunt-umd, the default use-case is to include BrowserFS as a JavaScript file on your page, much like jQuery, and without any module loaders. We could potentially offer a -umd.js version, but I'd rather have a universal JS file to avoid confusion if it's possible to set it up that way.

timdream commented 9 years ago

On it.

timdream commented 9 years ago

Regarding automating the process with grunt-umd, the default use-case is to include BrowserFS as a JavaScript file on your page, much like jQuery, and without any module loaders. We could potentially offer a -umd.js version, but I'd rather have a universal JS file to avoid confusion if it's possible to set it up that way.

The pull request is now producing an universal version.

jvilk commented 9 years ago

Working on it in browserify branch...

jvilk commented 9 years ago

I'm almost done with this. I need to fix a unit test bug, then I need to test the built/minified files. Once that's done, I can merge into master and make a release!

timdream commented 9 years ago

Woot!

jvilk commented 9 years ago

Right now, this bug is the holdup:

https://github.com/Microsoft/TypeScript/issues/2953

I'm using tsify, which gives us the ability to use watchify. tsify forces us to use TypeScript 1.5 beta, which has the above-linked issue with lib.d.ts.

Even if I hack fix this in my code by defining DataView.d.ts myself, the node.d.ts typings on DefinitelyTyped still reference DataView and fail to compile:

https://github.com/borisyankov/DefinitelyTyped/issues/4249

For some reason, it seems impossible to tell tsify/browserify not to abort builds if there's a typechecking error. Normally, TypeScript will happily emit JS for TypeScript code that fails to typecheck so long as the files parse properly.

jvilk commented 9 years ago

Have I mentioned that I spend 50% of my time on build-related bugs? What a mess!

jvilk commented 9 years ago

OK. We're now on npm and, thanks to @timdream's help, we can handle just about any module system you throw at us (falling back to a global when none present).

wjordan commented 9 years ago

Woohoo! Thanks so much for getting this set up! I'm looking forward to linking this into a test project, I'll share the results as soon as I have something working (perhaps I'll try to contribute an npm/Browserify example to the README when ready).