search

embroider-build / embroider

Compiling Ember apps into spec-compliant, modern Javascript.
MIT License
333 stars 136 forks source link

Support efficient rebuilding of addons #253

Open thoov opened 5 years ago

thoov commented 5 years ago

Converting the points that @ef4 brought up here: https://github.com/embroider-build/embroider/pull/246#issuecomment-504063683 into an issue that we can track. The TLDR is that addons (both in-repo and external) are blocked from "rebuilding" due to: https://github.com/embroider-build/embroider/blob/25671a8b43d8938d4c66d3de2fc92acd58563fd6/packages/compat/src/compat-addons.ts#L76-L80

Two initial approaches stand out on how to solve this:

  1. Do some kind tree diffing to determine the actual change set (as @ef4 called out in #246)
  2. Add functionality into broccoli to "pass forward" change information such that: https://github.com/embroider-build/embroider/blob/master/packages/core/src/wait-for-trees.ts could use it.
ef4 commented 5 years ago

I'm fine with both approaches, but if we add a hard dependency on a new broccoli version it needs to be a version that is broadly backward compatible. I don't want apps to need to upgrade a lot of things to try embroider.

(I'm also assuming we get to control the broccoli version used in Embroider, which I think is true but I haven't looked in a while. If we're stuck with a broccoli version from whatever ember-cli people are using, we can't depend on a new feature.)

stefanpenner commented 5 years ago

@ef4 it may be fair to couple embroider to some minimum version of ember-cli no?

Or we want make it a "progressive enhancement" like thing, where the newer version you have the better things work?

ef4 commented 5 years ago

Yes, but right now that minimum is something like 3.4.

If we to suddenly bump it to 3.12, the number of apps who can easily test without spending dev cycles on upgrading things goes down a lot.

simonihmig commented 3 years ago

Just stumbled upon this, as in-repo addons were not rebuilding, which is super annoying obviously. But given that #297 is already merged, this is actually fixable by setting EMBROIDER_REBUILD_ADDONS=my-addon, which is great!

I just wonder what's still needs to be done to make it work by default. Looking at the PR it seems this is related to using broccoli@v3, right? @embroider/compat still requires some 2.x version, is there anything that is blocking us from upgrading?

Either way, if users need to add one env var or the other (BROCCOLI_ENABLED_MEMOIZE looking at mayRebuild()), we should probably document this somewhere? As again not having this can be the cause of a lot of frustration...