Skip to content
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

Support for ember resolver v5.0.1 #102

Open
toranb opened this issue Oct 19, 2018 · 9 comments
Open

Support for ember resolver v5.0.1 #102

toranb opened this issue Oct 19, 2018 · 9 comments

Comments

@toranb
Copy link
Collaborator

toranb commented Oct 19, 2018

PR 243 for ember resolver removed the DefaultResolver that this hot loader relied on to properly resolve templates. I spent a good deal of time today trying to reverse engineer how we might otherwise resolve without the DefaultResolver but at this time I don't have a solution to write home with. If anyone has time to pitch in and unlock support for ember-resolver v5 that would go a long way to helping this project support ember-cli > 3.3

@rtablada
Copy link

@toranb we might need to ping @krisselden or @rwjblue?

This definitely hit me today and it was something I was surprised by in a new 3.5 project...

@rwjblue
Copy link
Member

rwjblue commented Oct 24, 2018

Can you share where we use the DefaultResolver in this addon?

@toranb
Copy link
Collaborator Author

toranb commented Oct 24, 2018

@rwjblue I didn't reach out on purpose so not to worry. I don't think this project warrants any type of core team support, etc. The fact that we hijack the resolveTemplate method in this addon is the issue. We need to re-think how this resolve works for the wrapper component (or extend outreach via RFC to prevent this type of issue from happening in the future as discussed in a few other forums).

As this happened I was in the middle of working to transfer the addon to a different organization (Adopted Ember Addons) in hopes that someone with more bandwidth and drive would feel up to resolve this + the other issues that have pop'd up since ember-cli v3.4 shipped.

I'll keep you all updated as this transfer happens if you want to partner up and source dive into resolver specifics at some point. Robert/ and I discussed landing a primitive "reload" like method that components could use helping this project eliminate the custom resolver altogether :)

That^ would be a huge step forward and I know something did actually land on ember master after EmberCamp in late September but I've not followed up myself to see what next steps look like.

@rtablada
Copy link

@toranb ah cool thanks for the extra context.

@lifeart
Copy link
Contributor

lifeart commented Oct 29, 2018

@knownasilya looks like you in context of resolver, do you have an ideas?

@knownasilya
Copy link

Not really familiar with the resolver to be useful here.

@MiguelMadero
Copy link
Collaborator

I was thinking, that at least for components we could use an HOC instead and just re-export the components instead of relying on the resolver. That way, as far as all ember code is concerned it will be a single component from the expected path but our exports would be rewritten to something like export default withHotReload(OriginalComponent)

@lifeart
Copy link
Contributor

lifeart commented Dec 9, 2018

@MiguelMadero ember-ast-hot-load addon doing kinda like this, replacing all component invocations with helper wrapper.

@MiguelMadero
Copy link
Collaborator

That's good to know, I wasn't aware of that addon. It has been a while since I worked with Ember, but I'm still keeping an eye on ember-cli-hot-loader and a few other things out of personal interest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants