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

Add Embroider support #34

Merged
merged 9 commits into from
Apr 12, 2021
Merged

Add Embroider support #34

merged 9 commits into from
Apr 12, 2021

Conversation

simonihmig
Copy link
Collaborator

Fixes #30

Embroider has a special dependency rule in place in to support the dynamic component pattern in Embroider, which made this addon work in Embroider for a while. However it seems embroider-build/embroider#608 added some stricter checks for dynamic component usage that again made this addon fail under Embroider.

This should now hopefully solve the issue once and for all, by wrapping the private -element helper in Embroider's ensure-safe-component, which also allows us to get rid of the -dynamic-element-* components (see code comment).

Tested this locally in an app, and added ember-try scenarios.

To my understanding the changes here should be ok, especially the use of the ensure-safe-component helper, but @ef4 if you have the time to give this a review from Embroider's perspective, this would be helpful!

@@ -89,7 +89,7 @@ module('Integration | Helper | element', function(hooks) {
{{#let (element "button") as |Tag|}}\
<Tag type="button" id="action" {{on "click" this.didClick}}>hello world!</Tag>\
{{/let}}\
', { insertRuntimeErrors: true }));
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed this as Embroider seems to have its own hbs babel-plugin, that throws when receiving more than one argument. I am not sure what this option does here, so please advice if/how this needs to be fixed!?

@simonihmig
Copy link
Collaborator Author

A few scenarios are failing, but it seems for unrelated reasons. Also the latest scheduled run on main had some failures...

@ef4
Copy link

ef4 commented Nov 17, 2020

Hmm, if you're able to delete the -dynamic-element components that seems like ensure-safe-component maybe isn't stable enough, and it could be hurting re-render performance.

@simonihmig
Copy link
Collaborator Author

Hmm, if you're able to delete the -dynamic-element components that seems like ensure-safe-component maybe isn't stable enough, and it could be hurting re-render performance.

I don't follow you tbh... just to prevent any misunderstandings: the -dynamic-element components are not used anymore in this PR. They are just still present as Embroider's dependency rule that I added a while ago still refers to them, and removing them here at this point in time would make Embroider complain about those missing.

@simonihmig
Copy link
Collaborator Author

A few scenarios are failing, but it seems for unrelated reasons.

Hm, not quite (re: unrelated):

addon/helpers/-element.js Outdated Show resolved Hide resolved
@ef4
Copy link

ef4 commented Nov 20, 2020

@simonihmig I confirmed that there's no stability problem in ensure-safe-component, so my fears above were unfounded.

Also, the problem you hit with ember beta is fixed by embroider-build/embroider#620 and will be released soon.

@simonihmig
Copy link
Collaborator Author

I updated the Embroider dependencies after its latest release, which makes most scenarios pass.
The still failing ones are:

  • default-jquery
  • classic
  • 3.4

The former two are unrelated to this PR, and failing with the same error on main due to set-env not working anymore

The last one is tricky. Seems the second argument ({ insertRuntimeErrors: true }) to hbs mentioned above is there to allow Ember <3.11 to compile the template. While at the same time this second argument makes Embroider throw a compilation error as mentioned.

I already tried replacing ember-compatibility-helpers with @embroider/macros, in the hope that the latter's dead branch elimination would make the offending hbs call be hidden from the template compiler. But it seems the template compiler's transform happens before that of @embroider/macros, so that doesn't help here.

So as it stand either the Ember 3.4 scenario or the two Embroider scenarios added here will fail with a build error. I have no better idea to solve this than to disable the 3.4 scenario!? 🤔

However we end up fixing this, it's certainly "just" a CI issue. Except for this, I believe the changes here should be fine now from my PoV, and looking forward for a final review! (as this is a blocking issue for some addon's embroider progess 😉 )
/cc @chancancode

@ef4
Copy link

ef4 commented Nov 29, 2020

@simonihmig I think the solution here is that Embroider needs to implement insertRuntimeErrors.

@simonihmig
Copy link
Collaborator Author

I think the solution here is that Embroider needs to implement insertRuntimeErrors.

I planned to do that, but time was flying away, and as it stands I am not able to do that in the near future, at least not in the remaining days of this year.

As stated above, the issue is "just" about testability, not the actual code. So is there a chance we can land this without being blocked on the test coverage here (again, the change in the actual code is blocking embroider adoption for some addons, at least ember-bootstrap)? @chancancode

@ef4
Copy link

ef4 commented Dec 19, 2020

insertRuntimeErrors is now implemented here embroider-build/embroider#658

@ef4
Copy link

ef4 commented Dec 20, 2020

Embroider 0.35.0 was released with support for insertRuntimeErrors.

@simonihmig simonihmig force-pushed the embroider branch 2 times, most recently from 10a1c7c to 83c7aeb Compare December 20, 2020 22:05
@simonihmig
Copy link
Collaborator Author

Embroider 0.35.0 was released with support for insertRuntimeErrors.

Awesome, thanks so much! 🙏

I previously replaced ember-compatibility-helpers with @embroider/macros, hoping to fix the insertRuntimeErrors issue by that, which did not work out. But I figured this change is useful by itself, so I pushed that here. Also Ember 3.25 Canary started to throw a different error for that "invalid usages: it does not take a block" test (related to this GlimmerVM update), so I also pushed a commit fixing that.

CI is "green" now (again, 2 failing jobs are broken on main branch also), so ready for a final review please! 🙏

@simonihmig
Copy link
Collaborator Author

As the CI failures on the main branch have been fixed meanwhile, I rebased this, and CI is green now!

Hope we can finally get this reviewed and eventually merged, to unblock Embroider adoption in the ecosystem! @chancancode @rwjblue

lib/element-helper-syntax-plugin.js Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
@chriseppstein
Copy link

Is there an ETA on landing this?

@simonihmig
Copy link
Collaborator Author

Is there an ETA on landing this?

Only waiting for final approval. @rwjblue I addressed your feedback long ago, could you please have another look?

@cibernox
Copy link
Collaborator

what's the status of this?

@simonihmig
Copy link
Collaborator Author

what's the status of this?

Same as 3 weeks ago:

Only waiting for final approval.

🤷‍♂️

@chancancode
Copy link
Member

We also needed to fix our embroider build at Skylight so we can look into merging and tagging it this week.

I am not sure I am the best person to catch mistakes relating to embroider itself, other than confirming that it does indeed work in the app. Anything you would like to call out specifically?

Sorry for the wait!

@simonihmig
Copy link
Collaborator Author

I am not sure I am the best person to catch mistakes relating to embroider itself, other than confirming that it does indeed work in the app. Anything you would like to call out specifically?

Not really. @ef4 and @rwjblue both did an initial review, and I think I have addressed everything. Also I am using this branch in an Embroider-built app, and this PR adds test coverage for Embroider, so I am pretty confident it does work as it should.

Copy link
Collaborator

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, sorry for the long delay again @simonihmig. I think the only thing remaining here is to bump the @embroider packages to latest, then we are good to go.

package.json Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
@simonihmig
Copy link
Collaborator Author

I think the only thing remaining here is to bump the @embroider packages to latest, then we are good to go.

@rwjblue rebased and updated all embroider dependencies!

@rwjblue
Copy link
Collaborator

rwjblue commented Apr 12, 2021

Thanks, sorry again for the delays.

@rwjblue rwjblue merged commit 334b844 into tildeio:main Apr 12, 2021
@chancancode
Copy link
Member

I can tag/publish – is this a minor or major bump?

@chancancode
Copy link
Member

I guess we are pre-1.0 so I will push a 0.5.0

@rwjblue
Copy link
Collaborator

rwjblue commented Apr 12, 2021

@chancancode - It should be fully safe (aka non-breaking)

@chancancode
Copy link
Member

Oops, pushed 0.5.0 already. I supposed it could have been 0.4.1 but doesn't really matter that much

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

Successfully merging this pull request may close these issues.

Is Embroider support on the roadmap?
6 participants