-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement LCA host/host addons logic in ember-cli
#9537
Conversation
8d12be2
to
d081ce5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor changes to ask for more descriptive member names and some more documentation of methods, but otherwise this looks good! Nice work.
6e0f2d8
to
459047b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found a few more cases that look like something is missing.
607c75d
to
1cbfc0d
Compare
1cbfc0d
to
cf76742
Compare
cf76742
to
cd59880
Compare
This PR implements host addons/LCA host logic in
ember-cli
and updates addon bundling caching to use these host addons, rather than only considered bundled addons by the project.An LCA host in this context is defined as the lowest common ancestor that is considered a host amongst all bundle hosts (engines/project) by the same name in the project.
The behavior in
ember-cli
needs to differ than the original implementation inember-engines
because we need to know this information up-front during addon instantiation, rather than after all addons in the project have been instantiated. As a result, the method for determining the LCA host/host addons is different: because we don't have access to addon instances, we usePackageInfo
objects to compute this information. It's worth noting thatPackageInfo
objects do not have knowledge of their parents, so we do a breadth-first traversal, keeping track of all paths until we discover the intended engine (represented by aPackageInfo
).For example, given the following project addon structure:
Similarly, we're also interested in all of the host package infos for a given LCA host; in the above example:
hostAndAncestorBundledPackageInfos
for each are considered to be:hostAndAncestorBundledPackageInfos
for lazy engine A includes all non-lazy dependencies of its LCA host & above (in this case, just the project)hostAndAncestorBundledPackageInfos
for lazy engine B includes all non-lazy dependencies of its LCA host & above (in this case, just the project)hostAndAncestorBundledPackageInfos
for lazy engine C includes non-lazy deps of lazy engine B & non-lazy deps of the project (LCA host & above)As part of this, we also expose a
getLCAHost
method so thatember-engines
can prefer to use this method if it exists; we prefer that the computation for all of this has a single source of truth for bothember-engines
and bundle addon caching.