Provide a way to augment global interfaces from external modules

[RyanCavanaugh]

We get "bug reports" of this nature very often:

I wrote this code

interface Window {
  myPlugin: any;
}
let x = window.myPlugin;
class Foo { }

then I added 'export' and I get compile errors, wat?

interface Window {
  myPlugin: any;
}
let x = window.myPlugin;
export class Foo { }

Our current answer today is "Move your stuff to another .d.ts file". This is an OK workaround, but not great. The real sticker is when there's a type defined inside an external module -- it's impossible to use those types to augment a global interface, even though this is a thing that actually happens. It gets even trickier because this encourages people to move types into the global namespace when they didn't want to in the first place, exacerbating the problem.

We need some proposal for how to make this work.

[kitsonk]

Am I being too ignorant, but why wouldn't the following be acceptable?

interface global.Window {
  myPlugin: any;
}
let x = window.myPlugin;
export class Foo { }

My particular use case was extending other global interfaces within a module that was going to try to offload to native if present:

interface ObjectConstructor {
    assign(target: any, ...sources: any[]): any;
}

const assign = 'assign' in Object ? Object.assign : function assign(target: any, ...sources: any[]): any {
    // shim...
}

export default assign;

[zpdDG4gta8XKpMCd]

Too bad there is no [discussion] tag, gonna add my few cents anyway. It's shocking how a big new feature is coming out of a tiny problem: to get something out of a standard object that is not supposed to be there. If so, what could be easier than this:

export function toSomethingCrazy(window: Window) : SomethingCrazy {
    return (<any> window).stupidPlugin;
}

That's it, the problem has gone. No need for a new expensive feature. Thank to one single guarded place in code.

[mhegazy]

@Aleksey-Bykov that does not allow for modeling global side-effects. a library author would want to declare that their library is adding certain definitions to the global scope, so that their users get to use them.

for context, we have rejected this in the past on the basis of discouraging bad practices. however, like them or not, there are existing JS libraries that relay on global extensions to work. the only way to do this today in TS, is to define your global polluters in a .d.ts file, then add a /// reference to it from your module.

[zpdDG4gta8XKpMCd]

well, can't say you have any other choice other than to add it
👍 for global polluters, I like the idea

[kitsonk]

It isn't just global polluters... The other use case is trying to extend the globals without having to load the full lib.es6.d.ts from within a module that is related to that bit of functionality.

[mhegazy]

@kitsonk can you elaborate..

[zpdDG4gta8XKpMCd]

@kitsonk, you sound like such pollutions would be localized in a module where they are introduced (rather than leaking to the global namespace) which sounds opposite to what @RyanCavanaugh originally said

[kitsonk]

All that is being suggested is that there is a language mechanism to access global interfaces from within a module. The reasons for it were originally thought to be useless which is why #983 got closed, then re-opened, and now closed again in lieu of this one. There can be many use cases, like having to do with other libraries that pollute the global namespace, which is bad, or my particular use case which is that I wanted to "shim" the global interfaces so I could better handle when the native ES6 functionality wasn't there. So one is the living in the sad reality of the wild west of the web and one might be actually a good thing, though it was better in the end for my use case to extend the global interface (#3889).

[IanYates]

Will this help fix code like

//file: frobulatorComponent.ts
namespace Components {
  export namespace Frobulator {
     export class ViewModel {
       public x = ()=> {
        var frobModel: Frobulator.Frob;   //.Frob isn't in intellisense (and this doesn't compile) 
             //since the global::Frobulator namespace is inaccessible   
             //("global::" chosen since it's used in other issues discussing this and nicely conveys what I mean)
        }
     }
  }
}

//file: frobulatorData.ts
namespace Frobulator {
  export interface Frob {

  }
}

I know there's a workaround where I could have

type Frobulator_Frob = Frobulator.Frob;

as the first line in frobulatorData.ts, but then I've got Frobulator.Frob and Frobulator_Frob in my global scope which is a bit untidy. If I have many interfaces in my global Frobulator namespace then I've got a lot of duplication to do.

I can fix this by changing some namespaces of course but global:: would be very handy. As I said in another discussion on this topic, the generated JavaScript is easy in this case - there is none since I'm just worrying about interfaces. I appreciate this would be more difficult with classes but not impossible (some auto-generated type aliases, with some sort of consistent name mangling, at the start of each ts file's emit would do the trick)

Note: I'm just letting VS 2015 build separate *.js files and using ASP.Net bundling to get them on to my page - no ES6 modules, gulp tasks, requireJS or anything like that.