Implement polyfill for globalThis

[tomduncalf]

What, How & Why?

This closes #4350. I decided to replace the existing inline implementations with a more robust polyfill taken from core-js, and to put it in realm.io/common so we don't need to always repeat the same snippet

☑️ ToDos

• 📝 Changelog entry
• 📝 Compatibility label is updated or copied from previous entry
• 🚦 Tests
• 🔀 Executed flexible sync tests locally if modifying flexible sync
• 📱 Check the React Native/other sample apps work if necessary
• 📝 Public documentation PR created or is not necessary
• 💥 Breaking label has been applied or is not necessary

If this PR adds or changes public API's:

• typescript definitions file is updated
• jsdoc files updated
• Chrome debug API is updated if API is available on React Native

[kneth]

Do we know if it has always been an issue - or was the bug introduced in a specific version?

[tomduncalf]

Good question, I will check the git history and see if I can tell

[kraenhansen]

I'm wondering if we could simplify the solution, but simply documenting the use of the @babel/preset-env Babel preset?

[tomduncalf]

I'm wondering if we could simplify the solution, but simply documenting the use of the @babel/preset-env Babel preset?

As in we say to users that they need to use @babel/preset-env in their project if they are on an old iOS version?

[kraenhansen]

As in we say to users that they need to use @babel/preset-env in their project if they are on an old iOS version?

Yeah. Or perhaps https://www.npmjs.com/package/babel-plugin-transform-globalthis? Since I don't see react-native in the supported targets of @babel/preset-env and it doesn't see like the metro-react-native-babel-preset is using it as is.

[kraenhansen]

Regardless: If we choose to discourage the explicit usage of globalThis, I think this PR should ensure eslint errors on that.

[tomduncalf]

I was following the pattern of what we've already done for globalThis in a couple of places, which is to fix our library so that it works with all supported OS versions. I think I prefer that approach (we do the nasty stuff so users don't have to do any workarounds) but I am also happy if the majority would prefer to ask users to install a Babel plugin for this reasonably edge case.

@kneth @takameyer any thoughts?

Good suggestion re: the lint rule

[kraenhansen]

we do the nasty stuff so users don't have to do any workarounds

I agree - and ideally we would apply this in a build step before publishing our package for consumption.
I'd expect this to be easier to implement in the future as I plan on adding rollup to the package as part of the binding generator project.

[tomduncalf]

we would apply this in a build step before publishing our package for consumption.

Got it, this would be the ideal (we use the Babel plugin on our code before publish). In the interim until we have the infra in place to do that (or can we do it right now?), are you OK with this solution?

[takameyer]

any thoughts?

I think we should do the work for our users here. If it's possible that we implement the babel plugin in our own codebase, I would prefer this.

[takameyer]

LGTM

[kneth]

any thoughts?

I agree with @takameyer

[tomduncalf]

@tomduncalf Add eslint rule

[tomduncalf]

@tomduncalf Plan: merge this PR, rebase v11 against master, rebase v11 PR to remove cherrypick commit and merge

[tomduncalf]

@kraenhansen I added the eslint rule in all public facing packages: b92a7f8

[tomduncalf]

If everyone is happy with this, I'll publish the new common version and rerun CI

[kraenhansen]

I added the eslint rule in all public facing packages: b92a7f8

I think it should be enough to add it to the root package and have the other packages inherit?

[tomduncalf]

I think it should be enough to add it to the root package and have the other packages inherit?

Ah I didn't realist that they inherited! Even better, I'll update