Using includeDirByFlag is causing runtime errors after Ember 3.4 upgrade about ember-cli-conditional-compile

[oscarni]

Encountered the same problem after upgrading from Ember 3.17 to 3.21. The unprocessed version of the initializer is included in the production build resulting in error Uncaught SyntaxError: Unexpected token 'export'.

Removing https://github.com/minichate/ember-cli-conditional-compile/blob/master/index.js#L114-L118 this first part of this if-statement makes the build load. The initializer in included in the production build, but at least it still works.

(Should mention that I also had this similar issue when upgrading to Ember 3.4. But I do recall that ember-cli-conditional-compile 1.1.1 fixed it.)

[kiwi-josh]

Update: It seems as though the conditional compiling works if I update route/controller/component in question to an ES6 class 🤔

Is this expected behaviour?

[lozjackson]

I have found this also.. If I use a version of Ember-cli >= 3.4 then the ember-cli-conditional-compile-features initialiser gets included in the production output:

...e.default=a})
import Ember from"ember"
var initializer={name:"ember-cli-conditional-compile-features",initialize:function(e){Ember.Logger.info("Initializing feature flags")}},feature_flags=EMBER_CLI_CONDITIONAL_COMPILE_INJECTIONS
Object.keys(feature_flags).map(function(e){window[e]=feature_flags[e]})
export default initializer
define(...

This causes an error Uncaught SyntaxError: Unexpected identifier.

Also, to add to this, If I use a version of ember-cli-conditional-compile >= 1.1.0, then the enableCompile property in the ember-cli-conditional-compile/index.js file is undefined resulting in the initializer being included in the output with the feature flags baked in. This means the feature flags are also added to the window object in production.

EDIT: after a bit more investigation, it seems to break at ember cli version >= 3.4.0-beta.2. ...and it works as expected (removes the initialiser) with version <= 3.4.0-beta.1

[halfbyte]

After lots of debugging last night, I think I found the cause of this error. The way the compiling has been reorganized for Ember 3.4 pushed a lot of code from broccoli/ember-app.js to broccoli/default-packager.js and in the process, we ended up with this new processAppAndDependencies method.

What happens there is that applyCustomTransforms takes the original tree, does some transforms (I think it's mainly there to process AMD modules), whereas processJavaScript takes the merged tree and does all the pre- and postprocessing (including the part in ember-cli-conditional-compile that is supposed to remove the module, but also doing the module wrapping), and when the result of those two calls gets merged, as the file is removed, it gets replaced by the unprocessed version of the module - if the module would not be removed, it would (as it's precedence is higher) replace the unprocessed version during the mergeTrees call.

I think this is an ember-cli bug?

[tehmaestro]

Hi, I encountered the same problem. I opened an issue on ember-cli.