Directory structure for node.js/express grunt workflow + ember-cli

Ember CLI
1

I am seeking recommendations for a directory structure which supports an automated frontend workflow for both “server side” and client (including ember) components. I’ve searched and read a lot on this but yet to find something I think works.

  1. The website has a lot of “non ember” pages - no need to make people download the entire ember libraries for landing pages, for instance. Currently the ember part is just one route in the server (e.g. /app) and everything else is managed server-side.

  • Our current structure is approximately:

  • lib

    • client
      • graphing
      • mapping
      • ember
      • global
      • vendor
    • server
      • MVC structure

  • public (built from lib/client)

  • Each of the lib/client subdirectories are built separately, e.g. into public/graphing.js, public/graphing.css, public/ember.js, public/ember.css, etc. Each page on the site usually includes global.js/css and 1-2 more. For instance, our ember app uses global, ember and mapping.

  • Our automated build/reload logic goes like:

  • If JS in lib/server changes, restart the node.js server and trigger a livereload

  • If any Jade in lib/server changes, trigger a livereload

  • If any lib/client contents change, then rebuild/bundle them into public

  • If anything in public changes, trigger a livereload

This is a pretty efficient structure and “front end workflow”, but how would I integrate the ember-cli world into it? One thing that’s very important to me is that the development environment is as close to the production environment as possible, so I really don’t like the idea of serving plus proxying the site using ember/broccoli in dev and serving it “normally” using express in production. In fact its our intention to adopt docker for the node.js+nginx part so that it’s exactly the same in dev as production.

One possibility would be that we just use “ember build” and hook it into our existing grunt workflow purely for the lib/client/ember building, but I have concerns about:

  • Speed, and particularly will broccoli support incremental builds that way?
  • Can ember-cli handle not having “every” lib/client included (such as global, vendor, mapping, etc) or being in control of public?

A second possibility would be if “ember serve” runs continuously but actually just build and writes the compiled ember.js and ember.css to disk so that we can serve them out of public like normal, but it doesn’t sound like it works that way.

I’m open to all ideas for how to refactor this as I don’t want to be left behind in an ember 2.0 world without ember-cli integrated.