1 | # moonboots
|
2 |
|
3 | A set of conventions and tools for building, bundling and serving single page apps with node.js and express.js.
|
4 |
|
5 | The bulk of the awesome bundling of CommonJS modules for client use is done using [browserify](http://browserify.org/).
|
6 |
|
7 | This just gives us a structured way to include non-CommonJS libraries, work in development mode and agressively cache built JS and CSS files for production.
|
8 |
|
9 |
|
10 | ## What it does
|
11 |
|
12 | 1. Saves us from re-inventing this process for each app.
|
13 | 1. Let's a developer focus on building a great clientside experience, not boiler plate.
|
14 | 1. Let's you use CommonJS modules to structure your clientside code.
|
15 | 1. Manages clientside files during development so you can just write code.
|
16 | 1. Compiles/minifies/uniquely named JS files (and CSS files optionally) containing your application allowing really aggressive caching (since the name will change if the app does).
|
17 | 1. Plays nicely with [express.js](http://expressjs.com), [hapi.js](http://hapijs.com), or even straight [node http](http://nodejs.org/api/http.html)
|
18 |
|
19 | ## Why?
|
20 |
|
21 | 1. Because single page apps are different. You're shipping an application to be run on the browser instead of running an application to ship a view to the browser.
|
22 | 1. Engineering a good client-side app requires a good set of conventions and structure for organizing your code.
|
23 | 1. Effeciently building/sending a client-side app to the browser is a tricky problem. It's easy to build convoluted solutions. We want something a bit simpler to use.
|
24 |
|
25 |
|
26 | ## How to use it
|
27 |
|
28 | You grab your moonboots and pass it a config. Then tell your http library which urls to serve your single page app at.
|
29 |
|
30 | That's it.
|
31 |
|
32 | ```js
|
33 | var express = require('express'),
|
34 | var Moonboots = require('moonboots'),
|
35 | var app = express();
|
36 |
|
37 | // configure our app
|
38 | var clientApp = new Moonboots({
|
39 | main: __dirname + '/sample/app/app.js',
|
40 | libraries: [
|
41 | __dirname + '/sample/libraries/jquery.js'
|
42 | ],
|
43 | stylesheets: [
|
44 | __dirname + '/styles.css'
|
45 | ]
|
46 | });
|
47 |
|
48 | app.get(clientApp.jsFileName(),
|
49 | function (req, res) {
|
50 | clientApp.jsSource(function (err, js) {
|
51 | res.send(js);
|
52 | })
|
53 | }
|
54 | );
|
55 | app.get('/app*', clientApp.htmlSource());
|
56 |
|
57 | // start listening for http requests
|
58 | app.listen(3000);
|
59 |
|
60 | ```
|
61 |
|
62 |
|
63 | ## Options
|
64 |
|
65 | Available options that can be passed to Moonboots:
|
66 |
|
67 | - `main` (required, filepath) - The main entry point of your client app. Browserify uses this build out your dependency tree.
|
68 | - `libraries` (optional, array of file paths, default: []) - An array of paths of JS files to concatenate and include before any CommonJS bundled code. This is useful for stuff like jQuery and jQuery plugins. Note that they will be included in the order specified. So if you're including a jQuery plugin, you'd better be sure that jQuery is listed first.
|
69 | - `stylesheets` (optional, array of file paths, default: []) - An array of CSS files to concatenate
|
70 | - `jsFileName` (optional, string, default: app) - the name of the JS file that will be built
|
71 | - `cssFileName` (optional, string, default: styles) - the name of the CSS file that will be built
|
72 | - `browserify` (optional, object, default: {debug: false}) - options to pass directly into browserify's `bundle` methods, as detailed [here](https://github.com/substack/node-browserify#bbundleopts-cb). Additional options are:
|
73 | - `browserify.transforms` (optional, list, default: []) - list of transforms to apply to the browserify bundle, see [here](https://github.com/substack/node-browserify#btransformtr) for more details.
|
74 | - `modulesDir` (optional, directory path, default: '') - directory path of modules to be directly requirable (without using relative require paths). For example if you've got some helper modules that are not on npm but you still want to be able to require directly by name, you can include them here. So you can, for example, put a modified version of backbone in here and still just `require('backbone')`.
|
75 | - `beforeBuildJS` (optional, function, default: nothing) - function to run before building the browserify bundle during development. This is useful for stuff like compiling clientside templates that need to be included in the bundle. If you specify a callback moonboots will wait for you to call it. If not, it will be run synchrnously (by the magic of Function.prototype.length).
|
76 | - `beforeBuildCSS` (optional, function, default: nothing) - function to run before concatenating your CSS files during development. This is useful for stuff like generating your CSS files from a preprocessor. If you specify a callback moonboots will wait for you to call it. If not, it will be run synchrnously (by the magic of Function.prototype.length).
|
77 | - `sourceMaps` (optional, boolean, default: false) - set to true to enable sourcemaps (sets browserify.debug to true)
|
78 | - `resourcePrefix` (optional, string, default: '/') - specify what dirname should be prefixed when generating html source. If you're serving the whole app statically you may need relative paths. So just passing resourcePrefix: '' would make the template render with `<script src="app.js"></script>` instead of `<script src="/app.js"></script>`.
|
79 | - `minify` (optional, boolean, default: true) - an option for whether to minify JS and CSS.
|
80 | - `cache` (optional, boolean, default: true) - an option for whether or not to recalculate the bundles each time
|
81 | - `buildDirectory` (optional, string, default: nothing) - directory path in which to write the js and css bundles after building and optionally minifying. If this is set, moonboots will first look in this folder for files matching the jsFileName and cssFileName parameters and use them if present. Those files will be trusted implicitly and no hashing or building will be done.
|
82 | - `developmentMode` (optional, boolean, default: false) - If this is true, forces cache to false, minify to true, and disables buildDirectory
|
83 | - `timingMode` (optional, boolean, default: false) - If set to true, moonboots will emit log events w/ a 'timing' flag at various stages of building to assist with performance issues
|
84 |
|
85 | ## About Source Maps
|
86 |
|
87 | Sourcemaps let you send the actual code to the browser along with a mapping to the individual module files. This makes it easier to debug, since you can get relevant line numbers that correspond to your actual source within your modules instead of the built bundle source.
|
88 |
|
89 | ## Methods
|
90 |
|
91 | **moonboots.jsFileName()** - returns string of the current js filename.
|
92 |
|
93 | **moonboots.jsSource()** - returns compiled (and optionally minified js source)
|
94 |
|
95 | **moonboots.cssFileName()** - returns string of the current css filename.
|
96 |
|
97 | **moonboots.jsSource()** - returns concatenated (and optionally minified css stylesheets)
|
98 |
|
99 | **moonboots.htmlSource()** - returns default html to serve that represents your compiled app w/ a script and optional style tag
|
100 |
|
101 | **moonboots.htmlContext()** - returns object w/ jsFileName and cssFileName attributes to pass to your http server's templating engine to build your own html source
|
102 |
|
103 |
|
104 | ## Full example
|
105 |
|
106 | For a working example, check out [moonboots_hapi](https://npmjs.org/package/moonboots_hapi)
|
107 |
|
108 | ## License
|
109 |
|
110 | MIT
|