Tsickle does not support intersection types, causing errors in declaration files

[engelsdamien]

This is related to #886, but in this case, when the type is declare'd, it means that some properties do not end up in externs files, causing them to be renamed by the Closure Compiler.

Typescript declarations:

declare interface Base {
  a: string
}

declare interface Complex {
  field: Base&{b: number};
}

Typescript code:

const complex: Complex = {
  field: {b: 3, a: 'hello'}
}

Generated externs:

/**
 * @externs
 * @suppress {duplicate,checkTypes}
 */
// NOTE: generated by tsickle, do not edit.
/**
 * @record
 * @struct
 */
function Base() {}
/** @type {string} */
Base.prototype.a;
/**
 * @record
 * @struct
 */
function Complex() {}
/** @type {?} */
Complex.prototype.field;

Closure output:

/**
 * @fileoverview added by tsickle
 * @suppress {checkTypes,constantProperty,extraRequire,missingOverride,missingReturn,unusedPrivateMembers,uselessCode} checked by tsc
 */

/** @type {!Complex} */
const complex = {
    field: { b: 3, a: 'hello' }
};

Compiled code (with rename-properties & generate-pseudo-names):

'use strict';
/**
 * @suppress {checkTypes,constantProperty,extraRequire,missingOverride,missingReturn,unusedPrivateMembers,uselessCode}
 */
const complex = {field:{$b$:3, a:"hello"}};

As you can see, the field param for the type Complex is defined as {?} which causes the field b to never appear in the extern. This causes Closure compiler to rename it in the resulting code.

[evmar]

I suspect the best thing we could do here is compile-fail on this code -- that is, reject your program entirely for using an intersection type in a 'declare' block. Do you have any other ideas?

[engelsdamien]

That would probably be better than the current behavior.

It might also be possible to support intersection types using extends, which Closure supports.

I think the code above is basically the equivalent of:

declare interface Base {
  a: string
}

declare interface __ExtendedBase extends Base {
  b: number
}

declare interface Complex {
  field: __ExtendedBase;
}

Which is something that Closure actually can encode.

The only issue is that it adds the extra __ExtendedBase name, I am not sure if there is a way to get an anonymous interface that does the same thing.

[evmar]

Historically we've tried to be clever and do these kinds of rewrites, but they always end up biting us. (For example what happens if you "&" two things -- you cannot extend two; or what happens if you "&" something with an overlapping field name.) I think my lesson has been it's better to force the user to rewrite in cases like this than to try to be clever.

[engelsdamien]

That makes sense

I guess then a compilation failure with a nice error message that suggests the rewriting is probably the next best thing

[SLaks]

Can you instead expand the intersection into its full resolved type?

declare interface Base {
  a: string
}

declare interface Complex {
  field: Base&{b: number};
}

/**
 * @record
 * @struct
 */
function Complex() {}
/** @type {{a:string, b:number}} */
Complex.prototype.field;

[mprobst]

SLaks: I think not, at least not in the general case. For example, the type could be recursive: ``` interface RecursiveIntersection { field: string&RecursiveIntersection; } ``` There are similar problems with generic type parameters and so on. I suspect it'll be very brittle to try and scope it down to a whitelist of supported cases.

[mprobst]

I think we'll have to close this as infeasible until Closure Compiler supports intersection types itself.

[mprobst]

Let me file a new issue to consider erroring out when we cannot represent a type in a .d.ts / externs file.