Define the "self" global name

[guybedford]

The most widely available global is self as it is in both workers and in the main window in browsers.

It would be very useful to define this global for cross-platform support.

As a further point it could even be worth having it replace window since typeof window is typically done for an isBrowser detection, while the same cannot necessarily be said of self.

[ztplz]

Why not use global, it is more clearly.

[benjamingr]

I recommend we go with global which is stage 3 and is in the TC39 process

[kitsonk]

@benjamingr which is now not going forward with global. I would be all for that except that it is now not going to progress until an alternative name to global is identified.

Because of the global debacle I would tend to agree with @guybedford while we await the outcome of the stuck TC39 proposal.

[benjamingr]

@ljharb - any strong opinions here?

[ljharb]

self is a terrible name, and the new name is already selected. global isn’t web compatible.

For something node-like, I’d suggest either providing what node does - global - or nothing, pending the new name landing in the language (which will never be “self”).

[benjamingr]

and the new name is already selected. global isn’t web compatible.

Well, if the new name is already selected - what is it? 😅

[ljharb]

Since it’s still in the process of shipping to browsers, and since there’s a real risk of trolling and of it being not web compatible to do so, I’m trying to keep it under the radar, and I’d ask everyone here to do so as well.

Please contact me privately if there’s an urgency to know.

[benjamingr]

@ljharb 😮 ok.

As far as I'm concerned there's no urgency to know. For what it's worth I think it's entirely reasonable for the TC to not put up with trolling at any amount or capacity.

I recommend we wait for the TC.

[ljharb]

I don’t necessarily mean in a specific arena; I’m talking like people putting up websites or publishing packages that intentionally conflict with the name.

[kitsonk]

My opinion then is to just wait for the public TC39 announcement. I don't think there is any rush, and TC39 should still be ahead of a stable Deno, would be my guess.

[MasterJames]

'self' gets my NeXT vote.
Personally nothing is like hoisting and makes lots of sense to me as well.

[ry]

Why don't we just use all of them? global, self, and window?

[ljharb]

Using window or self will absolutely break code that uses the presence of those things to test for "is a browser". Neither should be set in a server environment.

[MasterJames]

All works. Let there code break, easy to fix. I think there is better ways to test for browser. Maybe testing for browser on a server is not critical either.
Still if you think how javascript not strict mode hoisted variables all you need to do is remember to initialize and in a single threaded way with scope it's not a bad solution that originally existed. Anyway I always thought self should be implied. If you are in a function, and reference a value name that's not declared it should automatically imply it's in 'self'. Is that totally junior and stupid understanding or does it not make things better to imply self?

[GrosSacASac]

According to https://github.com/tc39/proposal-global/blob/master/spec.md
It would be globalThis

[ExE-Boss]

I personally prefer global, which was used by node, and the broken scripts use it for a browser/node detection.

Deno is probably closer to node than to a web browser.

See also tc39/proposal-global#36

[ljharb]

deno could certainly use global, just like node; but it'd have to also provide globalThis to be a compliant JavaScript engine.

[kt3k]

deno seems already having globalThis object (probably because of V8 update)

$ deno -v
deno: 0.2.3
v8: 7.1.302.4
typescript: 3.2.1
MacBook-Pro-3:~ kt3k$ deno
> Object.keys(globalThis)
[ "libdeno", "denoMain", "window", "atob", "btoa", "fetch", "clearTimeout", "clearInterval", "setTimeout", "setInterval", "Blob", "File", "URLSearchParams", "Headers", "FormData", "TextEncoder", "TextDecoder", "deno" ]

ref: https://v8.dev/blog/v8-release-71

[bartlomieju]

@ry is this still relevant with our current approach?

[kitsonk]

We have globalThis as part of the type definitions now, I say we close this.

[josephrocca]

@ry @kitsonk If we don't have self et al, then doesn't this mean that a bunch of code will need to be re-written to be compatible with Deno? I'm having to re-write all my Worker scripts right now which is kinda annoying. Not a huge deal, but I thought Deno was trying to be fairly compatible with the browser and node so that we can bootstrap off the existing ecosystem of js packages?

[MasterJames]

One can just patch like I make an 'und' that is 'undefined'... no? this = self or what have you. Anyway I would think it is not impossible to cover the bases internally by default and have all things desired or needed without a painful impact on performance or memory, or is that wrong in this case?

[ry]

Sorry I closed this too soon. I do want to have “self” in workers.

[kitsonk]

Yeah, sorry... The original post was suggesting self as the global for every runtime. globalThis and window for main thread runtimes, and globalThis and self for workers make sense.

Another somewhat tangental consideration is that we only have one type library. Ideally we would have 3 type libraries for Deno. One common, and then one small main runtime and one small worker library. We would also need to instruct the compiler if it is main or worker code to maximise the type safety.

I would suggest we tackle all this under a different issue though. I originally opened #1866 to deal with that, though it isn't explicit enough.

[ExE-Boss]

I still hate that the web global object is window, but this is sadly the reality we live in.

Deno could however decide to just use globalThis, which would refer to a generic global scope that only has the ECMAScript globals as its properties.

[ljharb]

globalThis is the global object - Function(‘foo = true’)() must create a foo property on it, so it can’t be restricted to just the language globals - it must include all globals.

For consistency with the web, any usage of windows or selfmust thus be=== globalThis`.

[ExE-Boss]

I meant only have the ECMAScript properties on it by default.

[craigfay]

@kitsonk I don’t disagree, but how did you come to the conclusion about dividing the type library the way you described? If #1866 is a better place for that discussion, I’d be curious to see your answer there.

[AviVahl]

might be worth mentioning that:

• upcoming ts@3.6 sets window as Window & typeof globalThis:
  Update DOM from TSJS-lib-generator microsoft/TypeScript#32335
• latest Chrome and Firefox has globalThis available.
• augmentation is quite straight forward:

declare global {
    function startsWithPound(text: string): boolean;
}
globalThis.startsWithPound = text => text.startsWith('#')
globalThis.startsWithPound('some text');

// above passes type checks and gets proper inference for function's argument.

[morille]

Is the support of "this" an option for Deno ?
Many libraries are using the global "this" keyword to get access to the global context.
I just migrated one of my projects to Deno and everything works well excepted this.

[ljharb]

@morille ES Modules must have their this set to undefined; it's only an option in sloppy mode Script. globalThis is the standard mechanism.

[morille]

@ljharb I understand that but it does not affect the main context AFAIK.

[ljharb]

It affects any place where import works.

[kitsonk]

We should close this IMO @ry. We have globalThis and window is defined as Window & globalThis now just like out of the box TypeScript. I am not sure what else we would want to do.