Declaration-emit class expressions as type literals

[sandersn]

Fixes #15066, although the resulting d.ts file is a bit ugly. After discussion, @mhegazy and I decided that adding a new "named class expression" type would not be enough to solve the problem on its own, making any complete solution extremely complex. Instead, this change just writes out class expressions as object types, resulting in types like this:

// @Filename: a.ts
class B { b; }
function f() {
    return class extends B { static d; }
}
// @Filename: a.d.ts
declare class B { b: any; }
declare function f(): {
  new(): { b: any };
  prototype: { b: any };
  d: any;
}

Notes:

1. Circular references bottom out as any.
2. This happens for all type writing, not just declaration emit, but this is probably a slightly improvement overall.

[mhegazy]

kinda weird that we keep this property. can we filter prototype out?

[sandersn]

Done

[sheetalkamat]

If there is a way to keep this as typeof Base it would be better I think. The completionlist/quickinfoes would get unreadable with this change otherwise

[sandersn]

Done

[sheetalkamat]

can you please add example like:

class Base {
}
export function foo() {
return class extends Base {
}
}

This should report error that Base is private and used here.

[sandersn]

I tried adding an ad-hoc check, but I couldn't get it to distinguish between this case, where the class expression extends a class declaration, and the mixin case, where the class expression extends a parameter. There are two problems with the latter case:

1. The mixed-in class could easily be a non-exported class declaration.
2. Class declarations that call the mix-in are no longer enclosed in the mix-in function, making it difficult to track back to the original class expression's context in the displayType machinery.

This export will not cause errors in any case, because the class expression is exported as a type literal, so Base isn't actually referenced — just its contents.

tl;dr — I don't think it's worthwhile to issue an error here.

[sheetalkamat]

Can you also add private member to this? Are we suppose to see private member in the type literal? If yes we should not be writing type of that private property/method because then it would likely start showing errors (with inaccessible symbol)

[sandersn]

Added test, and removed privates from declaration emit.

[sheetalkamat]

how about instead checking SymbolFlags.Prototype

[sandersn]

Good idea.

[sandersn]

All right, I think this change is ready to go in now. @mhegazy mind looking at the latest changes to emit errors for private properties that are part of exported class expressions?

[jtlapp]

Is it possible to apply this solution to mixins that use generics? I have the following mixins working, as long as I don't try to use them from within another module:

// broker.ts

export class BasicBroker<E> {
    doSomethingBasic(): E {
        //...
    }
}

export function SpecialBrokerMixin<E>() {
    return function <B extends Constructor<{}>>(Base: B) {
        // allows mixins to use decorators and be declared abstract
        class WithSpecialBroker extends Base {
            doSomethingSpecial(): E {
                //...
            }
        }
        return WithSpecialBroker;
    }
}

export function BasicSpecialBroker<E>() {
    // Can't pass a generic to a function. so make concrete first.
    class ConcreteBaseBroker extends BasicBroker<E> { }
    return SpecialBrokerMixin<E>()(ConcreteBaseBroker);
}

Here's what happens if I try to import them:

// app.ts

class AppEntity {
    //...
}

// Error TS4020: 'extends' clause of exported class 'AppBroker' has or is using private name 'ConcreteBaseBroker'.
// Error TS4020: 'extends' clause of exported class 'AppBroker' has or is using private name 'WithSpecialBroker'.

export class AppBroker extends BasicSpecialBroker<AppEntity>() {
    //...
}

I don't see how to define either ConcreteBaseBroker or WithSpecialBroker in ambient typings.

The following doesn't work, giving me the same errors, even in dev 2.8.0:

// broker.d.ts

export interface Constructor<C> {
    new (...args: any[]): C;
    prototype: C;
}

export interface BasicBroker<E> {
    doSomethingBasic(): E;
}

export interface BasicSpecialBroker<E> extends BasicBroker<E> {
    doSomethingSpecial(): E;
}

declare function BasicSpecialBrokerMixin<E>(): () => Constructor<BasicSpecialBroker<E>>;

[jtlapp]

I found the problem. The compiler --declaration option appears to break things. Everything works if I turn off that option. Should that be a bug report?