goog.require overloading cannot create an alias for a type

[rkirov]

With require overloading on strings, we can emulate:

var MyClass = goog.require('MyClass');

However this does not create a type alias for MyClass so the user cannot write:

var c: MyClass = new MyClass();

even though they can do

var c = new MyClass();

or even add their own type alias with type MyClass = typeof MyClass.prototype.

//cc @mhegazy

[mhegazy]

MyClass is a value, and not a type. it just happens to be a constructor function that when invoked with new operator returns objects of instance type of class MyClass.

so calling it with new will return the right thing, the problem is you can not name the type.

var myClassConstructorValue = goog.require('MyClass');
var myClassInstance = new myClassConstructorValue();

var anotherInstnace: typeof myClassInstance; // === type MyClass

I think what you want to say is something like microsoft/TypeScript#4233

[rkirov]

Thanks for the explanation, that makes sense and has a good consistent mental model. The way I see it var-binding can only introduce new values.

The missing context here is that we are trying to craft a .d.ts that would allow a .ts file to typecheck, source code that is using goog.require.

This issue is a bit of wishful thinking, because only natively supported module imports do cary types through. For example for node modules the following works:

    import MyClass = require('./myclass'); 
    var c: MyClass = new MyClass();

and similarly for ES6 modules:

    import MyClass from './myclass'; 
    var c: MyClass = new MyClass();

I don't see how even more generalized typeof statements would let us shim goog.require to behave like compile supported modules. Anything that makes the user type more than :

    const MyClass  = goog.require('myclass'); 
    var c: MyClass = new MyClass();

is a non-solution, as we don't want to expose too much complexity to the authors of that code.

However, we will work with Closure team to support ES6 import statement as a full replacement for goog.require, and side step this issue completely.

[mprobst]

We now have the machinery in place to drop goog.require and just use ES6 imports. Closing this issue.