Use core-js for getGlobals example

[Josh-Cena]

Summary

Motivation

Fix #10470. I hope this can reduce the confusion.

Also reverted back from const to var because this is verbatim-copied from the original code. Let me know if we still want to use const.

Supporting details

Related issues

Metadata

• Adds a new document
• Rewrites (or significantly expands) a document
• Fixes a typo, bug, or other error

[github-actions]

Preview URLs

• https://pr17337.content.dev.mdn.mozit.cloud/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis

Flaws

None! 🎉

External URLs

URL: /en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis
Title: globalThis
on GitHub

• https://github.com/zloirock/core-js (1 time) (Note! This may be a new URL 👀)
• https://github.com/zloirock/core-js/blob/master/packages/core-js/internals/global.js (1 time) (Note! This may be a new URL 👀)

(this comment was updated 2022-08-25 18:32:52.159186)

[zloirock]

It will fail in some cases. See https://github.com/zloirock/core-js/blob/master/packages/core-js/internals/global.js and zloirock/core-js#86 (comment)

[Josh-Cena]

Should we point to core-js then? We seem to use core-js links in more places.

[zloirock]

As you wish. I just pointed out that es6-shim is not the best option here.

[Josh-Cena]

Yes—I'm not sure about the editors' opinions on this, so just asking :)

[Josh-Cena]

@wbamberg What do you think here? Should we change the link and the code example to core-js's, or do we just apply the current change?

[wbamberg]

@Josh-Cena , I'd be happy to use core-js here instead, if you want to make that change :).

[Josh-Cena]

@zloirock One thing I'm unsure of: why is it necessary to check for it twice in it && it.Math == Math && it? I think I'm overlooking something.

[zloirock]

@Josh-Cena the first it is null check - typeof null is object. The second usage of it is returned result if the previous expression is true.

[Josh-Cena]

If it's null—the check would short-circuit and return a falsy value null already, and if it's not null—neither should the second round of check be falsy, right? I was asking if there's any difference from, say, it && it.Math == Math.

Ah, sorry, I see now. Thanks!

[zloirock]

You can check typeof setTimeout without globalObject, so I don't think that it's a good example. However, I'm not sure that it's in the scope of this PR.

[Josh-Cena]

Let's just remove it—we are showing globalThis anyway.

I realized that by removing it we are essentially providing a polyfill😅 Do you have a better use-case in mind?

[zloirock]

For me, it's for operations with global variables that are more complex than a simple check. For example,

if (!globalObject.Promise) {
  Object.defineProperty(globalObject, 'Promise', {
    value: function Promise () {
      // your Promise implementation
    },
    enumerable: false,
    configurable: true,
    writable: true
  });
}

[Josh-Cena]

Thanks, that's very useful inspiration—decided to use Intl instead of Promise so it looks more realistic.

[Josh-Cena]

👋 Anyone to review this? @wbamberg?

[Josh-Cena]

Trying to summon @wbamberg again since this one is quite small

[wbamberg]

Sorry to be slow @Josh-Cena .

[zloirock]

Now, without globalThis, it will not work in cases of ES-only environments (no one of the variables above) in modules context (IIFE this is undefined), where for security reasons disabled evaluation via eval / Function. It's not a big problem to create such an environment, for example, with NodeJS vm.

[Josh-Cena]

That's right—the purpose of this example is to illustrate what happens without globalThis. I did dig into the history of internals/global.js and it was something like this a long time ago: https://github.com/zloirock/core-js/blob/b4e8c0b09bbe23db8d8784df03ef0b8f3ff04170/packages/core-js/internals/global.js

[zloirock]

And after that, someone wrote me an issue about such an environment.

Someone could try to use the code from this example as a universal way of getting the global object and theoretically, it could fail in this specific and rare case. So I think changing "prior to globalThis ..." to something else could be better.

[Josh-Cena]

The only thing I've modified from the core-JS source is removal of the globalThis mention. In a runtime without globalThis, is there anything better than this?

[zloirock]

I mean that someone could try this code everywhere as something universal - in environments without globalThis and in environments with.

[Josh-Cena]

Oh well, it was kind of the same code before—let's hope no one uses it as a polyfill (they shouldn't!) If you want to add a warning box making it explicit, feel free to.

[wbamberg]

👍 thanks for your patience @Josh-Cena !