Dependancies not getting imported when leader parent has isEnabled hook that evaluates to false

[ghost]

Issue

After updating ember-auto-import to latest version we noticed that dependancies and dynamic chunks weren't getting imported in our production build.
After some debugging we found that the first ember-auto-import addon which was getting registered as the leader by the new protocol had ember-cli-fastboot-testing for it's parent.
ember-cli-fastboot-testing has an isEnabled hook which evaluates to false when app.env !== 'development so it's included hook was never getting called, and as a result ember-auto-import wouldn't import anything.

Steps to reproduce

git clone https://github.com/code-vuk97/ember-auto-import-bug
cd ember-auto-import-bug
npm run build

Repo in steps is a new ember app, the only new addons installed are ember-cli-fastboot and ember-cli-fastboot-testing.
Installed lodash via npm and used it inside of Foo component. If we serve the app in development mode it will work normally, but if we build for production lodash won't be imported and app won't work.

Workaround

As a temporary workaround for this problem because we work with a monorepo we put ember-cli-fastboot-testing into the before array of one of our addons so that our addon would run first and get chosen as the leader.

[ef4]

Thanks for the thorough bug report.

It would be good if we could take isEnabled into account when choosing the leader, but I don't know if we can get that information early enough. And there are other reasons why included may not run. Sometimes addons just forget to call super in their own included hook, or choose not to.

It seems we need to find a more robust place to hook into to ensure that the work we do in included can't be blocked by any other addon.

[vstefanovic97]

Yes, that seems like a hard task, maybe in the meantime, we could at least throw an error in case isEnabled evaluates to false. So that people will know what's wrong.

[josemarluedke]

I'm having this issue as well. Is there any workaround for an app that depends on ember-cli-fastboot-testing?

I have tried blacklisting ember-cli-fastboot-testing in the app, but no luck. If I remove that addon, I don't have this issue anymore.

Note: v1.6 of ember-auto-import does not have this problem, but I would like to keep up with the latest of the auto-import.

[vstefanovic97]

@josemarluedke if you are working with a monorepo you can use the workaround I suggested above.

[josemarluedke]

Yeah, unfortunately, I'm not working in a monorepo, just a standalone app.

[gfmartinez]

@josemarluedke Take a look at embermap/ember-cli-fastboot-testing#434
We had the same issue you mentioned in updating past ember-auto-import v1.6.0
With this branch/change we can update to ember-auto-import v1.10.1 with no issues, and all our fastboot tests are just fine. Hope that helps!

We are probably just going to point our dependency to our own fork until something is fixed, but if you need it: there's a potential solution.

[ef4]

This bug is fixed by ember-auto-import 2.0 because the parent is always the app's copy of ember-auto-import.