We have run into several challenges of feature detecting in an environment where browser features aren't always part of the "global" context. This is likely to result in several sub issues, so this will be created as an epic.
In addition, ECMAScript is likely to introduce a global reference, which like the NodeJS global is the best way to operate the "global" scope when running in a strict mode. (See dojo/shim#80)
There are several points we need to make sure that our code is "safe":
Feature tests (and even code using browser features) should reference the those features via window or global.window with an appropriate guard against window being undefined.
We need to type our global export, to include global.window as an optional property of type Window.
There maybe further regressions of any dependency on global when the order of precedence is changed in dojo/shim#80, but global being first is the most logical.
Bug
We have run into several challenges of feature detecting in an environment where browser features aren't always part of the "global" context. This is likely to result in several sub issues, so this will be created as an epic.
In addition, ECMAScript is likely to introduce a
global
reference, which like the NodeJSglobal
is the best way to operate the "global" scope when running in a strict mode. (See dojo/shim#80)There are several points we need to make sure that our code is "safe":
window
orglobal.window
with an appropriate guard againstwindow
beingundefined
.global
export, to includeglobal.window
as an optional property of typeWindow
.global
when the order of precedence is changed in dojo/shim#80, butglobal
being first is the most logical.