README.md

Ember CLI Config

Our configuration story has gotten us this for, but has become a liability.

we currently have 2 categories of configuration:

1. build tooling config: broccoli.js
2. ember app config: config/environment.js

Build tooling

Currently we are building a pile of un-maintainable scenario specific configuration flags partially drivin by the ENV and partially by user configuration.

These are confusing and unmaintainable. current stuff:

1. https://github.com/stefanpenner/ember-cli/pull/930/files
2. https://github.com/stefanpenner/ember-cli/blob/master/blueprint/Brocfile.js#L5-L11

I would like to propose, we break configuration + ENV up. In addition we should have general configuration flags, which tools can tap into and provide "sensible defaults".

By doing so, we should easily be able to support an arbitrary # of ENV configuration bundles.

Examples:

the following would enable all forms of hinting.

app.config('hinting', true);

the following would enable all forms of hinting, but disable PNG hinting.

app.config('hinting', true, {
  png: false
});

the following would enable all forms of hinting, but provide specific css hinting configuration.

app.config('hinting', true, {
  css: {
    mangle: true,
    base64Images: true
  }
});

config:

broccoli.js,broccoli/{production, development, test, ...}.js

app.config.<namespace>

app.config('hinting', true)
app.config('hinting', {
  css: true,
  js: false
}); // the semantics missing keys get default values

app.config('hinting', true | false /* default value */, {
  css: true,
  js: false
});

app.config('minify', true)
app.config('minify', {
  css: true,
  js: true
});// the semantics missing keys get default values

app.config('minify', true | false, {
  js: {
    mangle:   true,
    compress: true
  }
});

app.config('fingerprint', true);
app.config('fingerprint', {
  exclude: [],
  extensions: ['js', 'css', 'png', 'jpg', 'gif'],
  prepend: '',
  replaceExtensions: ['html', 'css', 'js']
})

app.config('sourceMaps', true);
app.config('sourceMaps', {
  js: true,
  css: false
});

// per plugin/addon configuration
app.config('broccoli-jshint', {
   // ...
});

// or (to prevent collision)
app.config('addon', 'broccoli-jshint', {
   // ...
});

Perf Environment configuration:

Currenty one can do if statements in the Brocfile, this works today but is suboptimal.

Brocfile // entry file
// will likely just require `./config/broccoli.js`, maybe the "app" + shared addons?

config/broccoli.js // shared for all environments.
config/broccoli/production.js
config/broccoli/<env-name>.js



Client Side configuration
-------------------------


In addition to configuration of our build-pipeline, we also must configure our client side app.
1. https://github.com/stefanpenner/ember-cli/blob/master/blueprint/config/environment.js

Example configurations are:

1. FEATURE flags
2. Logging rules
3. API urls
4. sha of build (for logging purposes)
5. ....

Our target output is JSON, or a JSON'eqs pure object literal on the ENV object.
This makes the transformation clear, simple and easily consumed on the client side.

.... how do we structure these so that they are nice.


Bonus
-----

on-boot use the es6-module transpiler to transpile the configuration files to CJS