TypeScript: In "declare global" blocks, allow access of block-scoped variables in globalThis

Cross-script boundaries are totally weird: a declaration will be visible for any subsequent script, but it is only visible to preceding code within its current script.

<script>
console.log(a); // Cannot find variable
</script>
<script>
console.log(a); // undefined
var a = 2;
</script>
<script>
console.log(a); // 2
</script>

I’m not sure what you mean by “native ECMAScript”. ModuleEvaluation and ScriptEvaluation are both top-level operations invoked by the host only, so you need a host to test them out, let it be Node or HTML. You never have access to the script scope in Node, but you can easily do this in HTML:

<script>
const a = 1;
</script>
<script type="module">
console.log(a);
</script>

If it interests you: https://tc39.es/ecma262/multipage/ecmascript-language-scripts-and-modules.html#sec-runtime-semantics-scriptevaluation, https://tc39.es/ecma262/multipage/ecmascript-language-scripts-and-modules.html#sec-source-text-module-record-initialize-environment

BTW, the “nesting” does not happen in a lexical sense. It’s merely that each time a script is evaluated, it directly uses the global scope, while when each module is evaluated, it creates a new scope that inherits from the global scope. There’s no closures.

Maybe someone will discover a reason that I’m wrong, but I think this is just a bug.

This might be the reason why ECMAScript didn’t have a standard global (AKA globalThis) for as long as it did - because it doesn’t behave intuitively. Until globalThis was standardized, we had window (browser) and global (Node), but they were always implementation-specific.

I think “script” is closer-to-the-metal while “global” is more abstract and fits user intuitions better.

I stand corrected. declare script would be worse.

Most people won’t run into the tiny nuances

People tell me this but I wonder… Could it be that people run into these issues more than it seems, but they lack the knowledge to bring it up? I’m not asking rhetorically, but I’ll offer my own experience:

window, global, and globalThis declarations worked the way I wanted occasionally, but not usually, and I could never get to the bottom of it. For the longest time, I thought it had something to do with the name of the declaration file and/or its path in my project and/or whether it’s in a node_modules subdirectory or not. Until I found this stackoverflow answer, I didn’t know what I didn’t know.

After reading it, I thought I had a solid grasp on what was going on. But it turned out I was mistaken. It wasn’t until this post that I learned it has more to do with JavaScript and “global” than TypeScript.

If I had the pressure of a deadline, I’d probably use (window as any), (global as any), or (globalThis as any) as a solution to get back to the main task at hand. When somebody solves the problem that way, their experience may never be shared with the TypeScript community.

This was kind of a rant, but it’s not directed toward you. I’m trying to learn why my experience feels like the opposite of “Most people won’t run into the tiny nuances.” (It will probably be explained by “Your experience is not the norm,” and I’m fine with that explanation, but I want to confirm with others before going with that assumption.)

@fatcerberus Sorry for reposting this comment. I made such a large edit it felt like a different reply.

in no world would a “global const” become a property on globalThis anyway

I was thinking this could have worked if the property was made non-writable (and non-configurable), but I guess yeah, the weird control-flow sensitive TDZ semantics would make implementing things that way unrealistic.

I think “script” is closer-to-the-metal while “global” is more abstract and fits user intuitions better. Most people won’t run into the tiny nuances—and in no world would a “global const” become a property on globalThis anyway 😉I don’t have strong opinions about the status quo.

TIL, thanks @Josh-Cena

@fatcerberus

Yeah, TS is just JS with compile-time types (plus a few value-add runtime features that got grandfathered in). So const has the same semantics in TS as in JS (or at least is supposed to).

Ah, I meant something slightly different. From that SO post:

On the other side, the following is possible, but the result is different:

export {}

declare global {
  let someLetString: string
  const someConstString: string
}

This only adds types for the following handles:

someLetString
someConstString

[As opposed to window.someLetString and/or globalThis.someLetString]

Although the ts compiler complains about window.someLetString and/or globalThis.someLetString not existing, I mistakenly assumed that during JS runtime, they would evaluate to the same value.