More Makefile hackery. Now we can make docs.

.gitignore

@@ -2,4 +2,4 @@ node_modules/*
 lib/*.js
 lib/*.map
 tmp/*
-
+doc/*

Makefile

@@ -2,27 +2,32 @@
 # across the wire.
 COFFEEC   := $(shell npm bin)/coffee
 UGLIFYJS  := $(shell npm bin)/uglifyjs
+CODO      := $(shell npm bin)/codo
 
 TESTFILES := $(wildcard test/*/*.js)
 TESTS     := $(TESTFILES:.js=.test)
 
-.PHONY: dependencies release dev test
+SRCS      := $(wildcard src/main/*.coffee)
+BINS      := $(SRCS:src/main/%.coffee=tmp/%.js)
+
+.PHONY: dependencies release dev test doc
+
+release: dependencies lib/browserfs.min.js
+dev: dependencies lib/browserfs.js
+test: release $(TESTS)
+doc: dependencies
+	$(CODO) --title "BrowserFS Documentation" src
 
-# Installs or checks for any required dependencies.
 dependencies:
 	@npm install
 
-release: lib/browserfs.min.js
-dev: lib/browserfs.js
-test: $(TESTS)
-
 test/node/%.test: test/node/%.js
 	node $^ > /dev/null
 
 tmp/%.js: src/main/%.coffee
 	node $(COFFEEC) --output tmp --compile $^
 
-lib/browserfs.js:
+lib/browserfs.js: $(BINS)
 	node $(COFFEEC) --output lib --compile --join browserfs.js src/main/*.coffee
 	node $(UGLIFYJS) -b --output lib/browserfs.js vendor/*.js lib/browserfs.js
 

README.md

@@ -6,13 +6,15 @@ BrowserFS is an in-browser filesystem that emulates the Node JS filesystem API a
 Browser compatibility
 ---------------------
 In general, BrowserFS has been tested to work in the following browsers:
+
 * TODO: Write up.
 
 However, not all filesystems support all browsers. To check if a filesystem supports the current browser at runtime, use the `isAvailable` method on the filesystem.
 
 Differences from Node
 ---------------------
 ### API Differences
+
 * BrowserFS only supports asynchronous Node API functions.
 * BrowserFS does not support symlink operations at this time; perhaps at some point we'll support BrowserFS-specific link files if this becomes important.
 * BrowserFS does not support watch/unwatch functionality.
@@ -21,6 +23,7 @@ Differences from Node
 ** Allowing number arguments to be passed as strings (e.g. '2' instead of 2).
 
 Why do we only support the asynchronous API?
+
 * Asynchronous methods allow you to use the filesystem across web worker boundaries using proxy file descriptors.
 * Asynchronous methods allow you to queue up multiple file upload/download requests for remote filesystems before they complete.
 * Honestly, it's just good practice. :)
@@ -33,6 +36,7 @@ In BrowserFS, a file descriptor is an object. However, this will not impact your
 Why write a file system driver for BrowserFS?
 -----------------------------------------------
 If you write a file system "driver" for BrowserFS, you get the following for free:
+
 * **WebWorker Support**: BrowserFS will automatically proxy file operations across the WebWorker boundary with no individual filesystem support required.
 * **Cross filesystem support**: BrowserFS will automatically handle operations that may span multiple filesystems. For example, if a user renames a file from `/mnt/dropbox/Foo.bar` to `/mnt/localStorage/Foo.bar`, BrowserFS will read the file from the Dropbox filesystem, write to the `localStorage` filesystem, and then delete it from the Dropbox filesystem. Filesystems do not need to know about each other.
 * **Test Suite Support**: BrowserFS (will eventually) contains a comprehensive test suite for each command type that can be run on any filesystem type. You can run the tests applicable to the filesystem commands that BrowserFS supports on your new filesystem without having to write the tests yourself.

package.json

@@ -22,9 +22,7 @@
     "coffee-script": ">= 1.6.2",
     "glob": ">= 3.1.21",
     "mocha": "git://github.com/pwnall/mocha.git#web-workers",
-    "uglify-js": ">= 2.2.5"
-  },
-  "scripts": {
-    "prepublish": "node node_modules/coffee-script/bin/cake build"
+    "uglify-js": ">= 2.2.5",
+    "codo": ">= 1.6.0"
   }
 }