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

fix optional chaining undefined for non macros #2215

Open
wants to merge 2 commits into
base: stable
Choose a base branch
from

Conversation

patricklx
Copy link
Contributor

@patricklx patricklx commented Dec 18, 2024

fixes #2212
fixes #1812

@patricklx patricklx changed the base branch from main to stable December 18, 2024 11:59
@patricklx patricklx closed this Dec 18, 2024
@patricklx patricklx reopened this Dec 18, 2024
@patricklx patricklx force-pushed the optional-chaining-undefined-for-non-macros branch from c5dff80 to b58baec Compare December 18, 2024 13:31
aKnownValue.foo = true;
result = aKnownValue?.foo;
`);
expect(code).toMatch(`result = aKnownValue`);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it still ?.foo?

Copy link
Contributor Author

@patricklx patricklx Dec 18, 2024

Choose a reason for hiding this comment

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

There are 2 runs with the same test. with and without preset env. So one converts it to manual null check, cannot make one version that matches both results

Copy link
Collaborator

@simonihmig simonihmig left a comment

Choose a reason for hiding this comment

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

Interesting one!

It seems the root cause of this is our Evaluator returning a confident result for that expression, which itself delegates this to babel's own NodePath#evaluate() which again returns a confident result. Seems basically the same as what @ef4 reported here already: babel/babel#14197

Even when that bug got fixed, I think the change here is good, as we only want to take the cost of that evaluation in the context of some get*Config call, which is basically what this PR is doing, right? So I wouldn't be surprised if this has also some performance benefits!

@simonihmig simonihmig added the bug Something isn't working label Dec 18, 2024
@patricklx
Copy link
Contributor Author

thats, right. only if its inside, or rather "part of" a get*Config call

@ArnaudWeyts
Copy link

I just patched the dependency with this PR and it does indeed fix our issues :) Thanks a lot for looking into it so quickly!

@ArnaudWeyts
Copy link

Anything that still needs to be done for this? Looks like one check is failing due to a browser timeout but seems unlikely that this change caused that failure 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants