Calling project.config() with an environment breaks addon supplied config

[davewasmer]

I'm not sure exactly what's going on here, but I've managed to boil it down to a minimal reproduction repo.

If an addon calls this.project.config('development') in it's setupPreprocessorRegistry() hook, it appears to break at least some (maybe all) addon-supplied config.

Reproduction steps

1. Clone down the repo
2. Run ember server
3. Inspect the contents of the config meta tag. Note the presence of the _APPLICATION_TEMPLATE_WRAPPER key in the encoded config object. This is the expected, correct behavior.
4. Open lib/bug-exposer/index.js
5. Add an environment parameter to the this.project.config invocation (i.e. this.project.config('development').
6. Restart the server
7. Inspect the contents of the config meta tag. Note the absence of the _APPLICATION_TEMPLATE_WRAPPER key in the encoded config object.

It appears that the act of calling this.project.config() with an environment parameter has caused the @ember/optional-features addon config to break.

Errata

I haven't figured out exactly what's going on here, but I figured I'd brain dump the boundaries of what I have discovered so far.

• I'm not sure if some or all addon-supplied config breaks. The test repo demonstrates the issue with @ember/optional-features. It's also impacting a private addon we are using in combination with ember-template-component-import which calls project.config in the setupPreprocessorRegistry hook.

• It can break from a deeply nested addon. I.e. an app will break if it depends on addon A, which depends on addon B, which makes the offending call.

[davewasmer]

Another interesting effect here:

After starting the server, if you save the consuming application's config/environment.js file causing a rebuild, the config loads correctly (both for that rebuild, as well as all subsequent rebuilds). However, rebuilds triggered by changing other files doesn't appear to correct the problem.