Cannot use properties as types

[jplaisted]

class Parent {}
const Obj = {};
Obj.Alias = Parent;
class Child extends Obj.Alias {} // Bad type annotation. Unknown type Obj.Alias

Link

The error here stems from the @extends {Obj.Alias} in the transpiled code.

This causes a bug in ES6 module rewriting. If a class is exported directly then things are fine:

export class Parent {
  static staticFunction() { return 'Parent.staticFunction'; }
}

import { Parent } from './input0';
class Child extends Parent {}

Link

Note the type annotation of the extends ends up being Parent$$module$input0.

But if we export using export specs there's an error.

class Parent {
  static staticFunction() { return 'Parent.staticFunction'; }
}
export  { Parent };

import { Parent } from './input0';
class Child extends Parent {} // Bad type annotation. Unknown type module$input0.Parent

Link

Note the type annotation is now module$input0.Parent.

Appears to be an OTI only bug, but seems pretty important.

[jplaisted]

I don't think we're going to fix the OTI issue but we can at least mark all exported types as @const to get around this. e.g.

class Parent {}
export { Parent };

Becomes

class Parent {}
/** @const */
module$foo.Parent = Parent;

[blickly]

I'm not sure I agree with the title of this issue. The first link looks WAI to me.

The third link is definitely wrong, but interestingly, doing the class transpilation by hand seems to fix the issue:
https://closure-compiler-debugger.appspot.com/#input0%3Dclass%2520Parent%2520%257B%257D%250A%250Aexport%2520%257B%2520Parent%2520%257D%253B%26input1%3Dimport%2520%257B%2520Parent%2520%257D%2520from%2520'.%252Finput0'%253B%250A%250A%252F**%2520%2540extends%2520%257BParent%257D%2520*%252F%250Aclass%2520Child%2520%257B%257D%250A%26conformanceConfig%26externs%3Dvar%2520goog%253B%250Agoog.inherits%253B%26refasterjs-template%26includeDefaultExterns%3Dtrue%26CHECK_SYMBOLS%3Dtrue%26MISSING_PROPERTIES%3Dtrue%26TRANSPILE%3Dtrue%26CHECK_TYPES%3Dtrue%26CLOSURE_PASS%3Dtrue%26PRESERVE_TYPE_ANNOTATIONS%3Dtrue%26PRETTY_PRINT%3Dtrue

This makes me think it's an ordering issue between ES6 class & module transpilation, rather than something more fundamental.

[jplaisted]

The first link works in NTI. So either a bug in OTI or in NTI, if behavior differs.

That aside I want to focus on that ES6 module issue, regardless of OTI/NTI.

If you expand your example to actually call goog.inherits you get the following:

/**
 @struct
 @constructor
 @extends {Parent$$module$input0}
 */
var Child$$module$input1 = function() {
};
goog.inherits(Child$$module$input1, module$input0.Parent);

Link

Note the @extends {Parent$$module$input0} but the the inherits call uses module$input0.Parent. This seems wrong to me.

Especially if you look at what goog.module does:

/** @const */ var module$exports$B = {};
/**
 @struct
 @constructor
 @extends {module$exports$A.Parent}
 */
var module$contents$B_Child = function() {
};
goog.inherits(module$contents$B_Child, module$exports$A.Parent);

Link

[ChadKillingsworth]

This affects module interop as well. CommonJS type node rewriting uses the goog module variation.

[jplaisted]

Just to be clear: my proposed solution is to mark exported classes as @const (regardless as to how they're exported) and then when importing always reference exports.Type rather than Type$local$name.

Chad does that work for you?

[jplaisted]

Basically the issue is that export class Parent{} is rewritten differently than class Parent {}; export { Parent };.

[blickly]

The typechecker only looks at the extends clause, so that's the only place that it matters in terms of what must be a type reference. That said, I'm fine with a simplification.

In the goog.module case, it rewrites the original definition to be on the exported name (e.g. module$exports$A.Parent) to avoid creating extra aliases. That is a good solution, but AFAICT, that rewriting is not currently happening for non-goog modules right now.

[ChadKillingsworth]

CommonJS and Goog Module both look to be in alignment here. So it's ES6 that's different.

Another solution would be to move the type node rewriting into a separate helper class and rewrite based of the module type. That's how I was going to solve this. You'd need the module type map which is currently part of #2729.