Added a check to enforce top-level dependency #290.

[dnalagatla]

This PR adds a check to enforce top-level dependency requirement for ember-fetch addon.

[stefanpenner]

This looks good, but there is a more concise API that could be used:

project.findAddonByName('ember-fetch') https://github.com/ember-cli/ember-cli/blob/807f56e2e434f716757de02fd1f2c3251dadaf6f/lib/models/project.js#L634

I noticed this method was listed as private, but it's intent was to be public so I've fixed that:ember-cli/ember-cli#8621

[stefanpenner]

Another approach, would be to do this work in the init() would be via this.project.dependencies['ember-fetch']

This approach would allow us to disable nested ember-fetch instances via isEnabled() { } hook, whereas if isEnabled returns false, we won't hit the included hook.

[dnalagatla]

This looks good, but there is a more concise API that could be used:

project.findAddonByName('ember-fetch') https://github.com/ember-cli/ember-cli/blob/807f56e2e434f716757de02fd1f2c3251dadaf6f/lib/models/project.js#L634

I noticed this method was listed as private, but it's intent was to be public so I've fixed that:ember-cli/ember-cli#8621

I made the change to use findAddonByName API for checking if addon exists. Also, updated the condition to check if the app has ember-cli-fastboot. If that addon exists and ember-fetch is not included throw the error.

[dnalagatla]

Another approach, would be to do this work in the init() would be via this.project.dependencies['ember-fetch']

This approach would allow us to disable nested ember-fetch instances via isEnabled() { } hook, whereas if isEnabled returns false, we won't hit the included hook.

I am just wondering, using above approeach and disabling nested fetch can have any side-effects.

[xg-wang]

@dnalagatla @stefanpenner
Just to clarify the hard requirement is for Fastboot support. In app without Fastboot, the problem of nested ember-fetch (or any addon with a custom vendor roll-up) is the first-write-win conflict.
@dnalagatla Can you also update the Readme, moving top-level addon from Use with Fastboot to upper level so it's no longer fastboot specific?

[dnalagatla]

@xg-wang, I agree. I will update the readme to make this the requirement.

You are correct this issue is Fastboot specific and if apps are using fastboot, the ember-fetch as nested dependency fails to set up the fetch module. Apps not on fastboot, I think there should not be an issue.

@stefanpenner @xg-wang
What do you think about checking if the application includes ember-cli-fastboot as a dependency before checking if ember-fetch is installed as a top-level dependency? This way we can keep the text as it is in readme, as current text makes more sense.

[xg-wang]

@dnalagatla Is this PR ready to merge? This requires a major bump that can go together with #348.