2.2.2 breaking change: globals are now 'not in scope' for templates? about babel-plugin-ember-template-compilation HOT 4 OPEN

I would like common casts added to the list: Boolean, String (helpful for glint)

And utility namespaces: Math, JSON, Date, URL

And Common globals: window, document, navigator, localStorage

Tho, given the congern ef4 raises, i can deal with destructuring globalThis, as awkward as it is. Tho, elements must all be lowercase, so the namespaces and casts seem safe

from babel-plugin-ember-template-compilation.

LIke #38, this was intentional because in general there's no way to statically disambiguate between javascript globals and future ember keywords. That is the tradeoff of not making people import keywords.

We do support globalThis, so I would expect @something=(globalThis.Boolean this.blah) to work.

We can decide to support a standard list of platform-provided globals, including Boolean and document. Perhaps we should do that right away to mitigate the impact of this change.

The thing we don't want to do is support arbitrary globals. Like, if somebody decides they don't like importing their component all the time and tries window.CustomButton = CustomButton, that doesn't make <CustomButton /> work in all components.

from babel-plugin-ember-template-compilation.

Another (IMO more important) consideration is html tags, or rather, for the scoping rule to work consistently across all positions (<___> vs {{___}}); say we support window and document, if HTML later introduces <window> or <document> elements, there will be no way to invoke them (without making convoluted excepts to the scoping rules)

from babel-plugin-ember-template-compilation.

Not to say that I am against supporting window or document for that reason, but we should keep that in mind every time we consider adding to that list

from babel-plugin-ember-template-compilation.