ember-cli-hot-loader icon indicating copy to clipboard operation
ember-cli-hot-loader copied to clipboard

Module unification support

Open lifeart opened this issue 6 years ago • 3 comments

I think it's a good idea to implement module unification support before official release

lifeart avatar May 14 '18 16:05 lifeart

If MU was actually in the beta right now I'd consider holding up a release. I'm planning to v1.0 before ember v3.5 is released because of the targetObject deprecation warnings you see today using this addon.

The v2.0 release will likely be MU only and at this point I couldn't even speculate about when that might happen. When MU lands in a beta release we can discuss this further but at this point in time it's not even on my radar

toranb avatar May 14 '18 16:05 toranb

As I see hot-loader implemented custom resolver (to get components/templates) can we use ember's resolver? (defined in application), It can solve part of problems like custom component locations & MU

lifeart avatar May 14 '18 16:05 lifeart

@lifeart not ignoring you btw - I just don't have the bandwidth to implement MU when the change itself is still behind a feature flag in canary if that makes sense.

I split my OSS time between a few projects and this one will see MU support when ember and the addon ecosystem have made the migration. At which point I plan to release the v2.0 that is MU only so it's aligned w/ ember-cli and users are provided a true OOTB (out of the box) experience for ember and hot reloading.

About your comments above- the magic of this project is that we hijack the resolver and insert a wrapper component that watches for events and invokes a re-render when the hbs/or JS of that component has changed. That involves a host of messy details and one strong motivation for v2.0 is that I can drop all of the legacy/ pods filesystem resolver hacks and "reboot" it to be MU specific. That 2.0 break also allows us to drop support for older versions of ember (such as 1.13/ etc) - if people still need to "hot reload" in the 1.13 or 2X series they can just use the 0.x or 1.x series.

One challenge I've found running this project specifically is that I'm not using a public api for anything and with each new release of ember I often need to look thru the changelog and find out what broke/ and how to fix it for the new stable release. At some point a true RFC/ etc would provide a more "blessed path" if that makes sense - something I simply don't have the time for right now but I'm happy to play an advisory role for others if they get ambitious in that regard :)

toranb avatar May 15 '18 16:05 toranb