Support either type asserting `self` in classes, or properly ignoring workaround

[alexkreidler]

I currently have a scenario very similar to https://github.com/microsoft/TypeScript/issues/2000#issuecomment-546929745. While it would be fixed it TS natively supported overriding class methods (see that issue), I followed the outline of the linked comment, but am running into a small issue. This is not a huge blocker but rather a nice-to have to get proper type completion for my scenario.

export class WritableObjStream<T> extends (stream.Writable as any) {
    writableObjectMode: true

    write(object: T, cb?: (error: Error | null | undefined) => void): boolean {
        return super.write(...more details)
    }
}

Because we type assert the base class to any, TS has no knowledge of the superclass. I tried a few solutions, with errors included below:

(super as any).write() // 'super' must be followed by an argument list or member access.

let s: stream.Writable = undefined;
// @ts-ignore
s = super // Identifier expected.

return s.write() // 'super' must be followed by an argument list or member access, Expected 1-3 arguments, but got 0.

Luckily, it autocomplete is picking up on the proper type of s.write() now and giving me an argument error. Also, from what I can gather super is treated as a keyword not an identifier, which results in the error above.

This may not be the most common of errors, but there may be a few scenarios/other use cases. I tried writing a few examples up but none made real-world sense besides this use-case of a workaround for overriding methods.

[alexkreidler]

Well, funnily enough, this works:

export class WritableObjStream<T> extends (stream.Writable as any) {
    constructor() {
        super({ objectMode: true })
    }

    write(object: T, cb?: (error: Error | null | undefined) => void): boolean {
        const swrite = new stream.Writable()
        let w: typeof swrite.write = super.write

        return w(object, cb)
    }
}

Obviously it has a performance issue, creating a new stream on each write call. We could avoid that by simply creating a local type which is that of each necessary function, at which point they could become out of date with the API/source, defeating their purpose. Chicken and the egg problem? Well I feel I've come in a full circle and for now might as well ignore trying to add types.

[RyanCavanaugh]

We should allow (super as T).prop using the usual skip-parenthesized-assertions logic we use elsewhere.

[Zzzen]

Would you elaborate on what skip-parenthesized-assertions is? Currently, this error is thrown by parser, should we move the logic to checker where the full ast is known? @RyanCavanaugh