Currently there is no disciplined way to interact with global libraries. Access is always via `js/foo`. Instead if we provide a non-clashing convention for talking about global libraries, interaction becomes more disciplined. Benefits include the ability to validate via externs when available:
For example:
But this will also work for many other contexts, say a JavaScriptCore application embedded in iOS:
This could also work for Rhino / Nashorn / Graaljs, for example:
There are two parts of to this task in order of priority:
Externs inference support for goog$global.Foo
Externs validation support for goog$global.Math
See also
With the latest update of I see this as somewhat redundant?
In the examples above the compiler has to magically “guess” what the user is actually referring to. goog is the actual provided “namespace” we have and global is a property of that, so it would make (:require [goog$global.Math]) somewhat logical without requiring the compiler to guess or maintain any kind of other index that would involve processing the actual source files.
Not a fan of having too much goog in my source files so maybe we could just have global as a “known” prefix (eg. global$Math) and emit goog.global or whatever else the platform prefers under the hood?
I’m ok with global instead of goog.global. But we have to handle this case explicitly so it doesn’t seem redundant?
Maybe allow (:require [$Math :refer (max)]) as a shorthand for global? Meaning no prefix before '$' to assume global?
Might make sense to use globalThis as a prefix for global, given that the JS world seems to have settled on globalThis and it already being available in many Browsers.
Removed the alias requirement from the issue description. goog$global works for now.