Hmmm. I'm going ahead with the merge of this, even though it doesn't completely fix the problem. Simple cases work fine (like the test I added), but most of the improvement I saw in chrome-devtools-frontend happens because we resolve properties from the base class as having type any. I'll investigate and file separately since this fix works for most cases.

Here is the reduced repro for the part of the problem that's not fixed:

var UI = {}
UI.TreeElement = class {
    constructor() {
        this.treeOutline = 12
    }
};
UI.context = new UI.TreeElement();

class C extends UI.TreeElement {
    m() {
        // should error on these two lines, but doesn't
        this.doesNotExist
        this.treeOutline.doesntExistEither()
    }
};

This gives a noImplicitAny error for UI and UI.context (since they reference themselves, they need a type annotation), but no other errors. The error correctly points out that you can annotate UI or UI.context to avoid the problem; the simplest way is to put /** @type {*} */ on top of UI.context.

The reason for the error is that the fix in this PR still checks the type of any initializer that is not a JSContainer, such as UI.n = 1, in case that type is null or undefined or contains them. When the initializer references UI, as new UI.TreeElement() does, then the circularity is hit again and UI's type just becomes any. So C effectively extends from any.