But you can:

declarefunctionnewInstance<T>(c:new(..._:any)=>T):T;varx=newInstance(classX{y=1;});x.y=2

Okay, I could include that, but I bet it has some limitations like not having type information about the static members of the class, right? I'm 95% sureClass<T> in Flow includes the static member types

Well, It's not clear how you want to use it. Flow has some limitations too, it's not like that in all scenarios you just get thestatics part with this annotation. It's still a generic, (but the last Flow version I've used is 0.85). But, TS is anyway not the best in inference ofstatic properties and even when it's suppose to have the information.

declareclassHi{staticsss():number;iii():string;}varh=newHi();h.constructor.sss();//            ^^^ <- Error in TS - Works in Flow

This case works in Flow at least:

declareclassHi{staticsss():number;iii():string;}functionfoo<T:Hi>(cls: Class<T>){cls.sss()// no errorcls.aaa()// Cannot call `cls.aaa` because property `aaa` is missing in statics of `Hi`}

I'm just saying if we include a note aboutnew (..._: any) => T types, we should mention that it definitely doesn't capture static member types, but thatClass<T> can.

In the moment you add: in the generics it's become pointless. It's not a "real life usage". Because I would probably write it as:

declareclassHi{staticsss():number;iii():string;}functionfoo(cls:typeofHi){cls.sss()// no errorcls.aaa()// Cannot call `cls.aaa` because property `aaa` is missing in statics of `Hi`}

I think that this demo is quite pointless. You better right about the fact that TS is really weak about static fields and you cannot get them throughconstructor, aka:

consth=newHi();h.constructor.sss();// <- Error, doesn't know `sss` exists

ButClass<T> utility isn't that different thantypeof. The fact TS doesn't recognizestatic fields is the real different.
If you wouldn't use: in the demo, only if a function isn't exported it might work and than you wouldn't need any type annotations (this is where Flow shines).

• I didn't talk about TS vs Flow. I've gave examples where Flow is better than TS
• Overtype, wasn't said about comparing to "losing needed type information", was about doing sophisticated types that aren't give any type safety, only use-less meta data
• I don't saysequelize definitions are over-typed (By the way I guess in TS it would done very differently). I said giving overtype examples for non-real life senecrious isn't good a thing.

The main point, I thinkClass<T> vstypeof T isn't a good example, because it's misleading and unclear to the point, But showing TS can't handlestatic properties or "prototype chain" is way more relevant while Flow does it

Okay, I'm just having trouble understanding why you're against my proposed changes. Would you be in agreement with something like

The TypeScript equivalent ofClass<T> istypeof T in cases whereT is a value, andnew (..._: any) => T in cases whereT is a type; however, unlikeClass<T>,new (..._: any) => T doesn't capture static class member type information.

I should research whethertypeof T captures static class member type information either though (though if it doesn't already, I would expecttypeof T to capture static members in the future, whereas I assumenew (..._: any) => T will never capture static members.)
Or can you propose how you would describe the differences in typing classes, including typing static members?

Okay for reference with latest typescript playground:

classFoo{staticbar:number=2}constTypeof:typeofFoo=Fooconsta:string=Typeof.barconstNew:(new(..._:any)=>Foo)=Fooconstb:string=New.bar

const a: stringType 'number' is not assignable to type 'string'.(2322)Property 'bar' does not exist on type 'new (..._: any) => Foo'.(2339)

So it's not correct to say that TS can't handle static properties; it certainly does withtypeof, it just can't do so on a generic type, and this is a concrete difference from Flow I think it would benefit people to know.

So I think anything we document about differences in class typing must discuss bothtypeof T andnew (..._: any) => T, the differences between each, and the fact that Flow can capture the class static member types even when theT inClass<T> is a type parameter.

TS don't dealstatics as part of prototype object well.typeof SomeClass will work as much astypeof anyInstanceObject. ButanyInstanceObject.prototype.constructor.* won't work in TS, Only in Flow.

I didn't say I'm against, I'm not a maintainer of this project and don't decide what goes in or not.

I think it's misleading to present it as "Class<T> vstypeof T". It's not the important part for my opinion and quite misleading. Talking about limitation to extractstatic properties from TS comparing to Flow is way more important and accurate

It's very important for people migrating from Flow to TS to learn what to use instead ofClass<T>. They need to know that they won't be able to fully replicateClass<T> in some situations.

I get thattypeof T is not the only answer, my TS section needs to mention bothtypeof T andnew (..._: any) => T to provide a complete answer. You may only usenew (..._: any) => T but it's not necessarily sufficient for everyone's purposes.

But you can:

declarefunctionnewInstance<T>(c:new(..._:any)=>T):T;varx=newInstance(classX{y=1;});x.y=2