-
Notifications
You must be signed in to change notification settings - Fork 630
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
Lacking support for ES6 block scoping #575
Comments
cc @Huxpro, @mganandraj, @JasonVMo |
Hermes’ behavior is how for-in and for loops behave, but i believe for-of loops specifically address this (ie, the issue is correct) |
hey @ljharb could I just ask you to rewrite your comment
in a bit of a more verbose/n00b-friendly fashion? I've read it I think 5 times now but I still don't understand what you are saying 😓 |
This is not related to Object.defineProperty(). Hermes does not fully support ES6 or ES6 block scoping in particular (nor does it claim to). FWIW, we don't support You need to run the source through the regular Babel pipeline, resulting in the following, which does execute correctly:
|
Object.defineProperty
is returned
Thanks for the explanation and workaround, @tmikov. That pushed me in the right direction. 😄 |
FWIW, we have had ES6 block scoping in the works for a very long time, but we are finding it difficult to integrate since the changes are pervasive and it is very disruptive to the entire project (compiler, interpreter, debugger, affects almost every single compiler test, etc). |
@tmikov any movement on this over the past year? This feature would be greatly appreciated by a lot of people I think trying to use alternative bundlers to work around the limitations of metro. |
OMG in my case the variable was got absolutelly from another block. Now the app has unexpected behavior in the production. Something like this with redux-saga:
Expected output '1' but it's '2' Hope ES6 block scoping will supported soon |
Hi all, Indeed hermes' current behavior w.r.t. block scoping is pretty surprising -- it happily accepts As @tmikov has been mentioning, this is a fairly invasive change, and we've been trying to figure out a strategy to complete the work in the least disruptive way possible. Ideally, any ES5-lowered code wouldn't be affected, at all, by the block scope-related changes. I have been working on this change for a while, and we are optimistic about being able to finally merge the work. You may notice that I merged over 20 diffs today -- those are all related to the block scope work (removing some assumptions, refactoring other parts of the code etc). Unfortunately, there are still a fair bit to be merged, so it could be a while until Hermes has block scoping support. |
@jpporto Would be great to switch for ESBuild for metro |
same bug
Expected output 'onClick 1' but it's 'onClick 2' https://hermesengine.dev/playground/ I will come to migrate the big react native project to hermes engine my app work with typeScript Config my |
Hermes will support block scoping in the next major revision. Since EcmaScript compatibility is tracked separately, closing this issue. |
@tmikov |
@YOEL311 when we release the next major version of Hermes, it will probably be source level compatible with RN 69. However I don't think that RN backports new Hermes versions to older version of RN, so you might have to do that yourself. |
@tmikov |
@YOEL311 what do you want to do yourself? |
@tmikov |
sidenote: @tmikov so just to be clear, this will be available with RN 73 (the current main branch version) correct? |
@kelset No. Hermes releases are not synchronized with RN versions. We don't have a definitive public timeline for the next major Hermes release yet. |
gotcha - thanks for clarifying 👍 once you have an estimated ETA for the next major can you let me / the release crew for RN know so that if it's "around" when we'll plan to cut the 0.73 branch we can make sure to make the two happen sequentially? (first Hermes, then we cut 0.73) |
@kelset I am not really sure about the schedule of RN releases, but my gut feeling is that RN shouldn't wait for the next version of Hermes. There are major changes coming to Hermes for the next version, like 6-month stable releases, bytecode stability, better ES6 compliance, much better numeric performance, and more. I hope we will be able to start talking more about it soon. It is indeed a very interesting question whether the 6-month release cycle of Hermes should be synchronized to RN releases, or RN should just pick the current stable Hermes release at any point. We are also seriously thinking about improved ABI stability, which might make this question less important. |
makes sense - no worries, we'll check back around when 0.73 will be cut to see how's it going on this end. |
Edit: |
To be more precise, it is not paused, but it is targeting the next major release of Hermes, not the next release of RN. The distinction is subtle but important. |
See updated comment here: #575 (comment) |
@tmikov do we have any ETAs yet for the next major of Hermes? |
@kelset some time in 2024. I wish I could be more specific. |
Bug Description
There is a bug in
Object.defineProperty
that always returns the last set property regardless of what property is being accessed.gradle clean
and confirmed this bug does not occur with JSCHermes version: 0.8.1
React Native version: n/a
OS version: n/a
Platform: arm64-v8a, x86_64
Steps To Reproduce
Run the following code example with
hermes-engine-cli
andnode
, and compare the output:Output:
The Expected Behavior
This should throw
copy: a = a, b = b, c = c
, as Node does:The text was updated successfully, but these errors were encountered: