You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When ember-fetch is only present in a project as a transitive dependency, it breaks in FastBoot because its updateFastBootManifest hook is never invoked. This has resulted in issues for a number of addons that depend on ember-fetch, and in the wild, someaddons have started installing it in the host project in their default blueprint to work around the problem.
I chatted with @kratiahuja in Slack a bit, and it sounds like it would be reasonable to start invoking that hook for nested addons. This would make it so that it doesn't matter whether an addon is a direct or indirect dependency, which is consistent with how addon-introduced content generally works otherwise, but it also raises a question: what (if anything) should ember-cli-fastboot do about the possibility of duplicate assets winding up in the manifest?
One option would be to say addons need to guard against this themselves, e.g. by checking whether an asset they want to include is already present, but that seems like sort of a footgun given that it's something that every implementation of the hook would likely need to remember to do.
Alternatively, ember-cli-fastboot could dedupe by path in the vendorFiles and appFiles arrays, in a similar way to how ember-cli dedupes app.import()ed files. That raises some of the same questions about which duplicate(s) get removed, since order could matter in those arrays.
I'm happy to open a PR, assuming there's consensus on an approach for handling (or not handling) the duplication question.
The text was updated successfully, but these errors were encountered:
I ran into this today. Wondering if there's a recommendation for addons that use ember-fetch as a dependency?
Edit: For my use case I was able to get away with using whatwg-fetch, but I also saw the ember-fetch recommendation here is to have the host app install ember-fetch as well.
Thanks for finding and explaining this issue Dan! It helped me understand what exactly was going on.
When
ember-fetch
is only present in a project as a transitive dependency, it breaks in FastBoot because itsupdateFastBootManifest
hook is never invoked. This has resulted in issues for a number of addons that depend onember-fetch
, and in the wild, some addons have started installing it in the host project in their default blueprint to work around the problem.I chatted with @kratiahuja in Slack a bit, and it sounds like it would be reasonable to start invoking that hook for nested addons. This would make it so that it doesn't matter whether an addon is a direct or indirect dependency, which is consistent with how addon-introduced content generally works otherwise, but it also raises a question: what (if anything) should
ember-cli-fastboot
do about the possibility of duplicate assets winding up in the manifest?One option would be to say addons need to guard against this themselves, e.g. by checking whether an asset they want to include is already present, but that seems like sort of a footgun given that it's something that every implementation of the hook would likely need to remember to do.
Alternatively,
ember-cli-fastboot
could dedupe by path in thevendorFiles
andappFiles
arrays, in a similar way to how ember-cli dedupesapp.import()
ed files. That raises some of the same questions about which duplicate(s) get removed, since order could matter in those arrays.I'm happy to open a PR, assuming there's consensus on an approach for handling (or not handling) the duplication question.
The text was updated successfully, but these errors were encountered: