Allow configuration for other environments.

[g-cassie]

Added support for other environment configurations. I am using ember-cli-mirage in development so needed a new environment to configure for running against my backend's development server.

// Example `config.js`
module.exports = {
  django: {
    buildEnv: 'django',
    store: {
      type: 'redis',  // this can be omitted because it is the default
      host: 'localhost',
      port: 6379
    },
    assets: {
      // ...
    }
  },

  // other environments
};

// command line
ember build --watch --environment=django

[g-cassie]

I realize now this PR will break your deployment if you are using ember-cli-deploy and have remote server configs in your deploy.js. I think it might be necessary to introduce a flag to get around this - thoughts?

[elucid]

Hmm, how about checking config[environment].buildEnv === "development" rather than environment itself. That way you could configure multiple development environments and not worry about accidentally running on staging/production.

[g-cassie]

I have different settings in my Brocfile for the django env so I don't think that would work. I don't think this niche either because if you want to support the ember serve development environment you will probably need to customize your index.html from what you would use to serve index.html from your rails backend (most likely to deal with rails template tags).

How about something like this:

// config/deploy.js
module.exports = {
  redisProxyEnvs: ['django']  // defaults to 'development'
}

// index.js
// ...
var supportedEnvs = !!config.redixProxyEnvs ? config.redixProxyEnvs : ['development'];
if (supportedEnvs.indexOf(environment) === -1){
  return;
}
// ...

[elucid]

I'm not necessarily opposed to flagging the envs you want to support, but I also don't understand the issue you are trying to raise above. My index.html is the same for the dev environment and production--it's not customized at all...

Why is it a problem to distinguish redis-proxied envs via buildEnv = "development" in the config?

[g-cassie]

Sure makes sense. I am referring to the "built" index.html being different. The index.html template is the same.

I have four environments:

1. development: I run this using ember serve. The backend is simulated using ember-cli-mirage so there is no actual backend (Rails/Django) running. This is where I am doing the majority of my development which is why I want to keep this name. When I am in this environment, all my urls in index.html need to be in this format <script src="/assets/vendor.js"></script>.
2. django: I run this using ember build --watch. I also run my django development server as a separate process. This is probably the same as your development environment. My urls in index.html need to be in this format <script src="http://127.0.0.1:8000/static/assets/dir/assets/vendor.js"></script>.
3. (and 4) staging/production: Index.html urls need to be in the format <script src="http://cloudfronturl/static/assets"></script>.

To get the right urls in each deployment I do the following in my Brocfile.js

var fingerprintOptions = {
  enabled: true,
  extensions: ['js', 'css', 'png', 'jpg', 'gif'],
};
if (env === 'production' || env === 'staging') {
  fingerprintOptions.prepend = 'https://12345.cloudfront.net/';
} else if (env === 'django') {
  fingerprintOptions.prepend = 'http://127.0.0.1:8000/static/';
} else {
  fingerprintOptions.enabled = false;
}

I am also using ember-cli-server-varaibles to make tags with preloaded data. This also results in split config depending on the environment.

// config/environment.js

```javascript
 if (environment === 'development') {
    ENV.serverVariables.defaults = {
      'csrf': 'abcd1234',
      'user-id': 1
    };
  }

  if (environment === 'django'){
    ENV.serverVariables.defaults = {
      'csrf': '{{DJANGO_CSRF_TAG}}',
      'user-id': '{{DJANGO_VARIABLE}}'
    };
  }

So if ember-cli-redis-proxy is going to use the "development" environment to build my app then I will end up with the wrong urls.

[elucid]

Okay I get it now. That makes sense. Let me think about this...