-
Notifications
You must be signed in to change notification settings - Fork 230
Getting Started
Ember App Kit's primary build tool is Grunt, a build tool written in Node.js. If you don't already have Node installed, you can get it from nodejs.org or your package manager of choice (including Homebrew on OSX).
npm install -g grunt-cli
This will install the Grunt command-line tool globally on your system. If you experience permission issues installing grunt see the Troubleshooting guide for more info.
You can confirm grunt-cli is installed by typing
which grunt-cli
This should print out the path where grunt is installed on your system.
git clone git@github.com:stefanpenner/ember-app-kit.git
Or you can download it as a zip to get started with the template.
cd ember-app-kit
npm install
This will install the dependencies Grunt relies on to build your project from source. This will create a node_modules
folder in your project and install the source for numerous NPM packages.
grunt server
point your web browser to
http://0.0.0.0:8000
Congratulations. Have fun using Ember App Kit.
grunt server
is the main task used for development. It runs a static Connect server for both your application and its tests, and will automatically rebuild your files in the background as you update them. For a full list of the build tasks that this runs, see your Gruntfile.js
.
Many apps use HTML5 pushState for their URLs. So you can reload the page after navigating to a URL, app-kit will serve the index.html file to any url that does not match an asset. If you follow a link to "/my_crazy_route" then reload the page, your app will still be loaded. You may wish to serve an alternative html file for the catch-all or disable this behavior: See tasks/options/connect.js
for this.
Rather than use AMD (Require.js) or CommonJS (Browserify) modules, apps built using the Ember App Kit use ES6 modules, which are built through the ES6 module transpiler. This means that you can build your apps using syntax that will be used in future JavaScript versions, but output AMD modules that can be used by existing JS libraries.
If you've built Ember.js apps before, you're probably used to stuffing everything into a global namespace, following naming conventions so the app can automatically resolve its dependencies (for example, App.FooRoute
would know to render App.FooView
by default). Using the custom resolver, Ember App Kit apps have similar abilities, but using ES6 modules instead of a global namespace.
For example, this route definition in app/routes/index.js
:
var IndexRoute = Ember.Route.extend({
model: function() {
return ['red', 'yellow', 'blue'];
}
});
export default IndexRoute;
Will be built to a module called routes/index
. Using the resolver, when Ember looks up the index route, it will find this module and use the IndexRoute
object that it exports.
Of course, while automatic resolving is awesome, you can always manually require dependencies with the following syntax:
import MyModel from "models/foo-model";
Which will load the default export (aliased as MyModel
) from app/models/foo-model.js
.
Ember.js has several template helpers that are used to easily resolve and render views and their contexts within a template. The resolver works with these helpers, too:
-
{{partial "foo"}}
will render the template withintemplates/foo.hbs
-
{{view "foo"}}
will render the view withinviews/foo.js
. -
{{render "foo" "bar"}}
will render the view withinviews/foo.js
using the controller withincontrollers/bar.js
Handlebars helpers will only be found automatically by the resolver if their name contains a dash (reverse-word, translate-text, etc.) This is the result of a choice that was made in Ember, to help both disambiguate properties from helpers, and to mitigate the performance hit of helper resolution for all bindings. The other option is to load it explicitly like so:
In app/helpers/example.js
:
var helperFunction = function(value, options) {
return value.toUpperCase();
};
In app.js
:
import exampleHelper from 'appkit/helpers/example';
Ember.Handlebars.registerBoundHelper('example', exampleHelper);
The default tests in Ember App Kit use the QUnit library. The included tests demonstrate how to write both unit tests and acceptance/integration tests using the new ember-testing package.
To run the tests in your browser using the QUnit interface, run grunt server
and navigate to http://0.0.0.0:8000/tests
. Note that just like your app, your tests will auto rebuild when grunt server
is running.
The app kit comes with a premade configuration file for running tests in Karma. Karma is a test runner developed by Google for easier cross-browser testing. By default, your app has three tasks for testing:
-
grunt test
runs your application's tests once using Google Chrome. It outputs code coverage information to the terminal and intmp/public/coverage
. -
grunt test:ci
runs your tests in PhantomJS, and is intended primarily for running on a CI server (such as Travis CI). -
grunt test:server
is similar togrunt server
in that it will automatically watch and rebuild your application on changes. It will also rerun your tests automatically when your code is updated. Unlike running the tests directly through the QUnit page, however, test results are output in the terminal and not the browser.
To modify these tests (including the browser used), edit tasks/options/karma.js
.
The app kit comes with a premade .travis.yml
to run your tests on Travis CI. Travis CI will run the test
script specified in your package.json
file. By default, this is is set to grunt build:debug test:ci
.
grunt build:dist
builds a minified, production-ready version of your application to dist/
. After building, you can preview this version with grunt server:dist
.
By default, build:dist
will minify and uniquely stamp app.css
, vendor.css
, your JS vendor dependencies, and your built app.js
and templates.js
. This task uses grunt-usemin and grunt-rev. See their documentation, as well as their task configurations and public/index.html
, for more information on customizing their behavior.
If you use Amazon S3 for hosting your assets, you may want to look into grunt-s3 for deploying your built application.
These are optional features your app can use.
You can use LESS, Sass (scss only), or Stylus by uncommenting the corresponding line in Gruntfile.js
and installing the appropriate Grunt plugin: (grunt-contrib-less
, grunt-sass
, or grunt-contrib-stylus
). By default, their tasks are configured to simply compile all of the *.less*
, *.scss
, or *.styl
files in app/styles
to app.css
in your output.
To enable CoffeeScript in Ember App Kit, you must first add grunt-contrib-coffee
to your NPM modules:
npm install --save-dev grunt-contrib-coffee
The modified package.json
should be checked into source control. CoffeeScript can be used in your app's source and in tests, just use the .coffee
extension on any file.
The ES6 module transpiler does not directly support CoffeeScript, but using them together is simple. Use the `
character to escape out to JavaScript from your .coffee
files, and use the ES6 syntax there:
# app/models/post.coffee
`import User from 'appkit/models/user'`
Post = Em.Object.extend
init: (userId) ->
@set 'user', User.findById(userId)
`export default Post`
Note that earlier versions of the transpiler had explicit support for CoffeeScript, but that support has been removed.
While the App Kit doesn't come with Ember Data, it can easily be added by downloading it to your vendor/
folder and adding a script tag for it in public/index.html
. You can also install Ember Data via Bower (see below).
Your app can optionally use Bower for managing your client-side dependencies (jQuery, Handlebars, and Ember). The directory is preconfigured to use Bower out of the box, but make sure you remove the pre-existing dependencies in your vendor/
directory from source control.