You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@weswigham:
So there's a bunch of ways to deal with that in modules w/o using a namespace, but I think the way that leaves the least undesirable types in a public namespace is to make a module like this:
// @filename: reexposedGlobals.d.ts
export type GlobalSVGElement = SVGElements;
And then add an import of that to the module which is going to shadow the global:
import {GlobalSVGElement as SVGDOMElement} from "./reeexposedGlobals";
Essentially, you use another real module as the scope you alias the globals in, instead of the scope outside a namespace.
We have plans in the future to make it possible to reference shadowed global in a less roundabout way similar to how import types let you dig into modules, but we're waiting on the escmascript globalThis proposal to finalize it's choice of identifier before we ship it.
The text was updated successfully, but these errors were encountered:
@weswigham:
So there's a bunch of ways to deal with that in modules w/o using a namespace, but I think the way that leaves the least undesirable types in a public namespace is to make a module like this:
// @filename: reexposedGlobals.d.ts
export type GlobalSVGElement = SVGElements;
And then add an import of that to the module which is going to shadow the global:
import {GlobalSVGElement as SVGDOMElement} from "./reeexposedGlobals";
Essentially, you use another real module as the scope you alias the globals in, instead of the scope outside a namespace.
We have plans in the future to make it possible to reference shadowed global in a less roundabout way similar to how import types let you dig into modules, but we're waiting on the escmascript globalThis proposal to finalize it's choice of identifier before we ship it.
The text was updated successfully, but these errors were encountered: