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

Update lib #137

Closed
wants to merge 1 commit into from
Closed

Update lib #137

wants to merge 1 commit into from

Conversation

Hatko
Copy link

@Hatko Hatko commented May 26, 2020

Summary

As discussed here, it makes sense to have lib consistent with the target.

Compatibility

OS Implemented
iOS
Android

@Hatko Hatko requested review from emin93 and radko93 as code owners May 26, 2020 14:52
@LinusU
Copy link
Member

LinusU commented May 26, 2020

Hmm, this will probably add new APIs that aren't yet present on React Native though 🤔

e.g. it would make definitions for BigInt available, but React Native doesn't support that: facebook/react-native#28492

@LinusU
Copy link
Member

LinusU commented May 26, 2020

added a more thorough explanation in the issue:

The reason why target and lib is set to different is because Metro will use Babel to transpile the syntax, which is what target controls.

On the other hand, lib specifies which part of the standard library exists, which isn't handled by Babel.

e.g. "syntax": "esnext" will allow you to use async function and await, which Babel can transpile. On the other hand, "lib": "esnext" will allow you to use BigInt, which will then fail at runtime because BigInt isn't supported...

@Hatko
Copy link
Author

Hatko commented May 26, 2020

@LinusU Interesting. Do you know if there is an official source where you can check the list of available/not available features? Or the rule of a thumb is not to use esnext at all?

@LinusU
Copy link
Member

LinusU commented May 26, 2020

@Hatko unfortunately not, I need to do some more investigation on this, but I believe that from React Native 0.63 (soon to be released) your code will either run on the engine from Safari 10, the bundled engine on Android, or Hermes.

With that information we should be able to figure out the correct target by using the Kangax tables: http://kangax.github.io/compat-table/es6/

edit: this also needs to be combined with the list here: https://reactnative.dev/docs/javascript-environment#polyfills

Or the rule of a thumb is not to use esnext at all?

I would advice against using esnext since it will automatically opt you in to any new features without knowing if they are compatible with your platform or not...

@LinusU
Copy link
Member

LinusU commented May 26, 2020

e.g. Promise#finally is not included in list of polyfills, is defined in lib.es2018.promise but is not available on iOS <11.3. Thus, setting lib to es2018 (or esnext) would allow people to write .finally on Promises, which would then fail at runtime.

@LinusU
Copy link
Member

LinusU commented May 26, 2020

From an initial reading, it seems like library could potentially be updated to ES2017 when targeting React Native 0.63 (only release candidate right now)

@Hatko
Copy link
Author

Hatko commented May 26, 2020

@LinusU Perfect, thanks for a comprehensive answer.

@Hatko Hatko closed this May 26, 2020
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.

2 participants