-
Notifications
You must be signed in to change notification settings - Fork 137
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
Fix branch elimination for macroDependencySatisfies
#1688
Fix branch elimination for macroDependencySatisfies
#1688
Conversation
thanks for submitting this! looks like you have some test failures there! |
Whoops, I thought they were all passing before I pushed. @NullVoxPopuli I added an extra case to handle macro compositions, but it's starting to feel a little hacky. An alternative to this PR would be to expand the docs to call out explicitly that |
c30f501
to
746124b
Compare
Hey tests were failing on strange type problems so I rebased this 👍 I also re-targeted it to stable so we can get the bugfix out the door |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great 🎉
Wow, that was simple! Thanks @mansona |
This is a follow up to #1468, and should fix ember-animation/ember-animated#647.
The problem is that #1468 only fixed branch elimination for non-runtime macros in JS/TS code via babel, but didn't fix it for templates via glimmer. This fixes
macroDependencySatisfies
by transforming it into amacroCondition
in the first pass, which will eliminate the branch in the second pass when it's used as a sub-expression.Writing code like
macroCondition (macroDependencySatisfies 'qunit' '^2.8.0')
will work, but is not ergonomic and is unfriendly.I don't think this needs to be done for
macroGetConfig
ormacroGetOwnConfig
.