-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
2.2.2 breaking change: globals are now 'not in scope' for templates? #38
Comments
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 We can decide to support a standard list of platform-provided globals, including 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 |
Another (IMO more important) consideration is html tags, or rather, for the scoping rule to work consistently across all positions ( |
Not to say that I am against supporting |
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 |
There appears to be a breaking change between
2.2.1
and2.2.2
. Previously, in gjs files, we could reference JS globals directly as helpers. For example, we were using@something=(Boolean this.blah)
to cast a value to a boolean.Now, we get the error:
Adding
const Boolean = window.Boolean
to the file works around the problem.This problem is not limited to helpers. Something like
{{document.title}}
previously worked, but now throws a 'not in scope' error.The text was updated successfully, but these errors were encountered: