[BUGFIX release] Only setup babel options once.

[rwjblue]

included is called for each instance of EmberApp created within the consuming applicationm, which means that we would be adding the same plugins if the consuming application happened to be creating two EmberApp instances.

For example, ember-cli-fastboot currently uses this technique to build both for fastboot AND the normal build. I know of a few other applications that use similar techniques to build two versions of the same EmberApp (i.e. a mobile version and a desktop one).

This allows us to ensure that this.options.babel is only setup once (regardless of how many times included is being called).

Fixes #4322.

[fivetanley]

We are working around this in ember-cli-fastboot by calling the function in ember-cli-build twice (creating two instances). This sort of feels like scenario solving; It feels like Ember CLI should have a better EmberApp cloning primitive so these kind of issues wouldn't happen. It also feels surprising as an addon author that things get called twice per instance.

[fivetanley]

I'll still merge once travis passes as a workaround. It feels like something is missing from the addon author perspective though.

[rwjblue]

@fivetanley - I don't feel like it is scenario solving. We only need to setup our addon's options once, not once for each time it is included into something else. Every time included is called we add more items to the list of plugins. Ideally this can go into init (I will test that actually), because it is one time setup stuff...

[rwjblue]

Yes, moving to init seems to work properly. Updated.

[bmac]

Looks like the build failed because a call to warnMessageForUndefinedType wasn't getting striped. Unfortunately I can't reproduce the error locally.

[rwjblue]

OK, updated again. Should fix the error that we were hitting before. When I moved the setup into init, the process.env.EMBER_APP environment variable wasn't set yet, so things were not properly stripped. That is why we changed this to be done in included to begin with and this is pretty annoying. I'll start thinking about a better solution, but I do think that this is a good enough work around for now...

[fivetanley]

r+

[lmcardle]

Any thoughts for users on the best workaround for now? I also just ran into this problem.

[fivetanley]

Can you tell us more about the situation you are running into this with? Typically it has been fastboot only as far as I can tell.

[fivetanley]

Otherwise you can use this addon from master.

[lmcardle]

Yes it was fast boot in my case. I'll use master as you suggest. Thanks.

On Wednesday, April 13, 2016, Stanley Stuart [email protected]
wrote:

Otherwise you can use this addon from master.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#4328 (comment)