src: add globalThis

[ljharb]

Per https://github.com/tc39/proposal-global, the global value globalThis should be configurable, writable, and non-enumerable, and be the global object.

I assume this PR is semver-minor.

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

This PR replaces #10405.

[targos]

I think it needs to be defined in https://github.com/nodejs/node/blob/master/lib/internal/per_context.js so that all V8 contexts have it, even the ones created by the vm module.

[mscdex]

Isn't this a bit premature? There doesn't even seem to be any real (recent) activity on this from any other browser vendor except Chrome/V8?

[ljharb]

@targos i ended up reverting it and directly backporting the v8 commits.

@mscdex i don't see why; this time we gathered web compat metrics beforehand.

[devsnek]

I was hoping this could just be backported from V8 upstream but it looks won't build...

@targosglobalThis is flagged in V8 70 and unflagged in 71, we could push out an alias in per_context but i worry it would be removed before it was used. Do you have any insight there?

[tniessen]

From the repository you linked:

it is on hold pending a new global identifier name

and

We are currently exploring identifier naming alternatives.

Is this not true anymore?

[ljharb]

No, neither are true anymore; i just missed a spot when updating it.

[jasnell]

would it be worthwhile emitting an experimental warning while this is still in early stages?

[ljharb]

I don’t see why; it’s not in early stages, it’s in stage 3, and v8 is shipping it unflagged.

[jdalton]

If this is coming to V8 does Node have to do anything?

[ljharb]

@jdalton nope, but if node wants to add it sooner than they update to v8 71 (or whichever version it's in), then this PR would be helpful for that - and i'd really like to see this global backported to v6 and v8.

[Trott]

Test LGTM. No opinion on the implementation or whether it makes sense to wait for V8 71.

(I think that's our first use of Function() in tests!)

[Trott]

Oops, I spoke too soon. Can we get rid of the string literals as the message values for the calls to assert.strictEqual(). (I have a lint rule ready to go to enforce this. PR coming probably later today or early tomorrow. There's a few things I want to get Just Right.)

Options include:

• Just use the first two arguments to assert.strictEqual() which will use default message (which will show the values of the first two arguments when there is an AssertionError). Optionally, change your third argument to a comment above the assert.strictEqual() call.

• Make the third argument a template string that will show the actual value along with your text.

• If you feel 100% confident that configurable, enumerable, and writable will be booleans and will never be something else, switch to assert.ok(actual, message).

[jdalton]

It looks like V8 v7 is coming ~Oct 14 #22754(which would be flagged support) and then unflagged the update after. I'm fine waiting ~month for this as experimental and the follow up as unflagged. There's no rush here.

[ljharb]

@jdalton at that point tho, wouldn't we still want to backport it to node 6 and 8? or are you saying it'd be easier at that point since the commits would already be in node master?

[jdalton]

We can revisit back-porting when it's unflagged.

[devsnek]

I don't think its crazy that we could ship es features independently of our underlying engine. maybe this is something worth discussing in the big picture?

[ljharb]

It is unflagged in v8. That that particular commit hasn't landed in node yet doesn't mean it's conceptually not ready to be shipped.

[jdalton]

I see no reason to step outside the normal rails of consuming V8 for this. We'll get this feature when it lands in the V8 Node consumes soon enough.

[addaleax]

@jdalton Being able to backport this to LTS release lines seems like a valid reason to me… any thoughts on that?

[devsnek]

@addaleax are we able to backport v8 70 and 71 in their entirety? the patches to v8 use apis only present in those versions. at that point we either have to make our own patch to v8, and at that point we might as well make the change like this pr does it.

I'm not against waiting for V8 versions, but rather unsure if we are able to backport it.

[addaleax]

@devsnek I would not think so. We may or may not be able to get 69 into Node 10, but 70 would be too late for the initial LTS release of Node 10, I think.

[jdalton]

@addaleax

Being able to backport this to LTS release lines seems like a valid reason to me… any thoughts on that?

See #22835 (comment).

[ljharb]

It’s already unflagged - so that means it’s time it revisit it now.

[jdalton]

I think we're talking past each other. I'm OK with globalThis but not OK implementing it here. I rather wait for the V8 consumed by Node to implement it. I'm OK back-porting a Node shim for this when the time comes (but it's not the time and this is not the PR).

[ljharb]

Can you elaborate on why? The proposal is stage 3; that’s the time for platforms to ship it.

[jdalton]

Can you elaborate on why? The proposal is stage 3; that’s the time for platforms to ship it.

Node will get it as soon as the V8 it consumes does. It's coming... just not-this-very-second and there's no real rush. It's a nice to have that's coming in a nice-to-have time.

[ljharb]

I hear that you don’t feel a need to rush - but since i (and likely others) do, perhaps you have more reasons then “i don’t feel it’s needed now” to push back against it?

[jdalton]

I'm familiar with the effort of globalThis(as a TC39 member I even OK'd its name at the last meeting) and I know you're the spec champion for it. The effort has been in the works for years off and on. I know you want it yesterday, but I'm saying no. No cuts. It will come soon enough.

[ljharb]

Can you provide a reason for saying no, though, besides "i don't want to rush"?

Also, I'm not sure why node needs to be held hostage to v8's release schedule for new APIs that don't require native support.

[jdalton]

@ljharb

Can you provide a reason for saying no, though, besides "i don't want to rush"?

I rather we get this without shimming (and it's coming soon). Adding the shim just to turn around and remove it is unnecessary and more overhead/juggling than it's worth. I'd like to avoid relying on per_context.js for it too since that has cross-engine issues.

[devsnek]

@jdalton per_context.js isn't v8 specific. it actually means node in chakra and v8 and whatever else would have globalThis. also I don't consider this a polyfill.

[jdalton]

@devsnek

per_context.js isn't v8 specific

I didn't say it was.

[devsnek]

@jdalton

I'd like to avoid relying on per_context.js for it too since that has cross-engine issues.

can you clarify?

[jdalton]

@devsnek

can you clarify?

Related problems: nodejs/node-chakracore#566.

[TimothyGu]

If node-chakracore cannot adopt the strategy used by this PR to add globalThis, then node-chakracore can certainly wait until ChakraCore adds support for it. I don’t remember seeing a policy where the feature set of node and node-chakracore must be in sync. Also, from an end user’s perspective there’s no difference in adding it now to node’s code versus V8’s code.

@jdalton would you be okay with cherry-picking the V8 patch that adds support for globalThis rather than doing it on the Node.js side?

As discussed at the TC39 meeting (which I am sure you remember) we want to aim to ship the feature as expediently as possible. I would really appreciate it if we could not block on what’s in my opinion a minor implementation detail.

[jdalton]

@TimothyGu

As discussed at the TC39 meeting (which I am sure you remember) we want to aim to ship the feature as expediently as possible.

I remember. However, I also remember the tail end of the presentation in which it was covered that there is no real smoosh or ticking clock concern (the TC39 won't be held up by malicious or bogus packages).

would you be okay with cherry-picking the V8 patch that adds support

If it's in the V8 we consume (cherry-picked in or otherwise) then it's in the V8 we consume.

[TimothyGu]

@jdalton

If it's in the V8 we consume (cherry-picked in or otherwise) then it's in the V8 we consume.

Awesome! @ljharb do you think you could backport the relevant V8 changes?

• v8/v8@620410a
• v8/v8@c8486d2
• v8/v8@b4b2daf

https://github.com/nodejs/node/blob/master/doc/guides/maintaining-V8.md#backporting-to-abandoned-branches should provide enough documentation on how to do so.

[ljharb]

@TimothyGu absolutely; i did that here for 2 of them but didn't follow the proper commit format. I'll update the PR to include those backports.

[refack]

/CC @nodejs/chakracore

[bugs181]

Where are we at with this? No activity since September, it's now 3 months later.

[devsnek]

I think the next V8 update has this unflagged (you can use it in node rn with --harnony-global)

[joyeecheung]

I think it's already unflagged on master?

[Trott]

I think it's already unflagged on master?

Correct. It's behind a flag in Node.js 11.5.0 (most recent release) but unflagged in master. This seems closable but a PR against 11.x-staging to float the relevant V8 patches may be desirable.

[Trott]

I'm going to close this, but please re-open or comment if you disagree that this ought to be closed at this time. I'm just tidying up and not acting on a super-strong opinion or anything like that.

[ljharb]

I’d still like to backport it if possible; I’m not sure if it’s worth repurposing this PR or not.