Setting consider_all_requests_local to true launches build_and_watch in non-dev environments

[kayakyakr]

This bit of code seems to default the environment to 'development' and overrides when consider_all_requests_local is set to true in other environments.

# /lib/ember_cli/helpers.rb

    def default_environment
      if Rails.env.test?
        "test"
      elsif Rails.env.production? || !rails_config_for(:consider_all_requests_local)
        "production"
      else
        "development"
      end
    end

This is particularly a gotcha in a staging environment which may be running requests as local. I don't know if it would be beneficial to remove that dependency, though. Have to watch that, as I had 4 build --watch instances running through various staging deploys.

It might be better to default to production for the ember env:

# /lib/ember_cli/helpers.rb

    def default_environment
      if Rails.env.test?
        "test"
      elsif Rails.env.development? || rails_config_for(:consider_all_requests_local)
        "development"
      else
        "production"
      end
    end

[seanpdoyle]

@kayakyakr thanks for opening this issue after resolving your strange behavior.

I'm a little confused by your suggestion:

Rails.env.development? || rails_config_for(:consider_all_requests_local)

Wouldn't consider_all_requests_local be set to false in your staging environment (in the scenario you've explained). Wouldn't this cause ember build --watch to be executed?

This behavior should definitely be explained better -- I'll likely open a PR against the README.

What is your particular use case?

You want to treat your staging requests as local, while not running ember build --watch (i.e. precompiling assets up front and serving them)?

[kayakyakr]

Hm, you're right, that doesn't really gain much. It actually just prioritizes consider_all_requests_local over environment.

Ideally, for me, anything that isn't development would come through as production, regardless of the state of consider_all_requests_local. The main purpose of that is to display rails server errors instead of generic errors, no?

Ember-cli doesn't have quite as much knowledge of dealing with non-standard environments as rails, from what I understand?

[seanpdoyle]

@kayakyakr does #366 seem like reasonable behavior?

[kayakyakr]

Looks good to me.