search

embroider-build / embroider

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

isDevelopingAddon() not respected #909

Open stefanpenner opened 3 years ago

stefanpenner commented 3 years ago

Today Addon's with isDevelopingAddon() === true file additions/removals are not reflected without server bounce.

This currently effects compat layer uses:

Discussion:

Should we fix the compat layer to handle this use-case, or should we focus on migrating folks to v2 (which does not have this issue). In my mind, this hinges on the cost of v2 migration for users, not the cost of our work to enable users to use v2.

Based on discussions with @krisselden @thoov @rwjblue we the current balance suggests we focus on v2, as the effort to comfortable fix this issue exceeds 1-2weeks of development. We can always revisit if needed.

ef4 commented 3 years ago

We need to add more discoverable docs on this, but the description in SPEC.md is still correct:

isDevelopingAddon: Dropped. This doesn’t belong in each addon’s code, it’s a runtime decision and control over it belongs in ember-cli proper. Under embroider developers can set a comma-separated list of addon package names in the EMBROIDER_REBUILD_ADDONS environment variable instead.

This issue covers automatically bridging to this new API for v1 addons, which I agree is a nice-to-have.

EMBROIDER_REBUILD_ADDONS is implemented and works for all addons, v1 or v2.

ef4 commented 3 years ago

I am also open to adding a new core option that would work similar to EMBROIDER_REBUILD_ADDONS with a potentially more expressive API. For example, you could declare that all addons with a certain prefix or within a certain local directory should be rebuilt. This is more practical for many environments.