restore tree caching via cacheKeyForTree

[RuslanZavacky]

Similar idea to the emberjs/ember-cli-babel#421, adding cacheKeyForTree helps to avoid calculate same trees multiple times when having addons inside addons.

[NullVoxPopuli]

Related question for @ef4, is this still a responsibility of the build system in a post addonV2 world? Or does the packager/webpack handle all that?

With v2 addons, is the v1 shim a no-op? (Assuming ember auto import v2 or embroider is present?)

[ef4]

We should indeed implement cacheKeyForTree here but I think we can use a very aggressive key, since v2 addons are never allowed to emit different content per consumer. Something like

cacheKeyForTree(this: AddonInstance, treeType: string): string {
  return `embroider-addon-shim/${treeType}/${directory}`
}

[ef4]

Related question for @ef4, is this still a responsibility of the build system in a post addonV2 world? Or does the packager/webpack handle all that?

With v2 addons, is the v1 shim a no-op? (Assuming ember auto import v2 or embroider is present?)

Even under embroider the shim is not yet quite a no-op. Not because anything in embroider needs it, but because @embroider/compat still bootstraps off ember-cli's EmberApp and Addon instances, and they need to see your addon as an Addon instance.

A v2-formatted app would be able to not care about the shims at all. But this isn't a thing that exists yet because it really wants to have all its addons in v2 format, and zero apps have that (given that ember itself isn't a v2 addon yet).

[RuslanZavacky]

@ef4 updated key 👌