helper for using emberjs with commonjs modules
Emberate is used to create a commonjs
require hierarchy for your Ember.js project structure,
mainly to be used for building with browserify.
For example, given the following structure:
app.jsrouter.jscontrollers/|_ user.js|_ user/|_ new.jsviews/|_ profile.jsmixins/|_ draggable.jsmodels/pods/|_ application|_ index|_ template.hbs|_ post/|_ route.js|_ index/|_ template.hbs|_ controller.js|_ edit/|_ template.hbs|_ route.js
Emberate can be used to generate a file that can be used as the entry point for browserify.
Install required packages:
npm install --save-dev emberate hbsfy handlebars ember-template-compiler browserify
Note: hbsfy can only be used for versions >= 2.1.0 and if using Handlebars >= 2, then the ember-template-compiler needs to be version 1.9.0-alpha or greater.
var emberate = require'emberate';emberate'./client' outPath: './client/.index.js'// './client/.index.js' now exists.. browserify it.;
From here you can run browserify:
browserify -t [ hbsfy -p ember-template-compiler -c Ember.Handlebars ] ./client/.index.js --outfile ./dist/scripts/application.js`
Emberate exports a function with the following signature:
emberate(path, options, callback).
lib/defaultTemplate.hbs(in emberate project) by default. - advanced options, only override if needed
emberate-addonsby default, the path that ember addons will be installed into.
falseby default, set to true to enable addon support
The callback is only fired if you specify
outPath in the options hash, e.g.
emberate'./client' outPath: './client/.index.js'// './client/.index.js' now exists;
Otherwise it's assumed that you are streaming and will create your own output file, etc..
For ease of use with npm scripts and for quick testing.
Usage: emberate [options]Options:-h, --help output usage information-V, --version output the version number-o, --output-path [path] Output path of generated file-i, --app-directory [dir] Directory to start crawling file tree-n, --app-name [app-name] App Name, where your app resides globally-m, --module-prefix [module-prefix] Module prefix, a namespace for app modules-p, --pod-module-prefix [pod-module-prefix] Pod Module Prefix, the directroy that the ember-resolver uses for pods
There is basic support for ember-addons. You should be able to npm install the addon, and assuming the published addon conforms to ember's addon standard, emberate will include the addon in your app bundle entry file.
You can optionally exclude the addon support from your build by setting
addonSupport to false in the emberate options. Since Ember Addons are normally written in es6, you will need to include a transpiler in your browserify bundle. The most simple way to do so is with the babelify transform.
Addon support is stricty tied to the addon itself, and if the addon is installing dependencies via blueprints, you will have to manually add the dependency to your project. This includes any css assets, preprocessors, or vendor libs that would normally be included in the ember-cli build pipeline.
Addon support is in very early stages, and will be further fleshed out as edge case issues are discovered. Please create an issue if you find an addon that does not work so that we can continue to find edge case issues and solve for them.
// creates a file with requires for App.* for embergruntregisterTask'emberate'var done = thisasync;var emberate = require'emberate';emberate'./client' outPath: './tmp/.index.js'done;;;
// creates a file with requires for App.* for embergulptask'emberate'var emberate = require'emberate';var source = require'vinyl-source-stream';return emberate'./client'pipesource'.index.js'pipegulpdest'./client';;
The concept and some of the code comes from Ryan Florence's loom-ember. Also lots of the work regarding streams and performance was done by Calvin Metcalf.