-
Notifications
You must be signed in to change notification settings - Fork 30k
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
src: add globalThis
#22835
src: add globalThis
#22835
Conversation
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 |
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? |
I was hoping this could just be backported from V8 upstream but it looks won't build... @targos |
Per https://github.com/tc39/proposal-global, the global value `globalThis` should be configurable, writable, and non-enumerable.
From the repository you linked:
and
Is this not true anymore? |
No, neither are true anymore; i just missed a spot when updating it. |
value: global, | ||
writable: true, | ||
enumerable: false, | ||
configurable: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be worthwhile emitting an experimental warning while this is still in early stages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t see why; it’s not in early stages, it’s in stage 3, and v8 is shipping it unflagged.
If this is coming to V8 does Node have to do anything? |
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 theassert.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
, andwritable
will be booleans and will never be something else, switch toassert.ok(actual, message)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@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? |
We can revisit back-porting when it's unflagged. |
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? |
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. |
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. |
@jdalton Being able to backport this to LTS release lines seems like a valid reason to me… any thoughts on that? |
@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. |
@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. |
See #22835 (comment). |
It’s already unflagged - so that means it’s time it revisit it now. |
I think we're talking past each other. I'm OK with |
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. |
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? |
I'm familiar with the effort of |
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. |
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. |
@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. |
I didn't say it was. |
can you clarify? |
Related problems: nodejs/node-chakracore#566. |
If node-chakracore cannot adopt the strategy used by this PR to add @jdalton would you be okay with cherry-picking the V8 patch that adds support for 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. |
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).
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? 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. |
@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. |
/CC @nodejs/chakracore |
Where are we at with this? No activity since September, it's now 3 months later. |
I think the next V8 update has this unflagged (you can use it in node rn with --harnony-global) |
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. |
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. |
I’d still like to backport it if possible; I’m not sure if it’s worth repurposing this PR or not. |
Issue on Jest jsdom/jsdom#2961 globalThis in Node.js nodejs/node#22835
Issue on Jest jsdom/jsdom#2961 globalThis in Node.js nodejs/node#22835
Issue on Jest jsdom/jsdom#2961 globalThis in Node.js nodejs/node#22835
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), orvcbuild test
(Windows) passesThis PR replaces #10405.