Construct Signatures and the Static Side

## Two names, two meanings TypeScript keeps declarations in separate *declaration spaces*: a type space and a value space. Most declarations land in only one. An `interface` or a `type` alias exists only in type space — writing it where a value is expected gives "only refers to a type, but is being used as a value here". A `const` exists only in value space. A **class** is the common declaration that lands in both, and this dual nature is what the question is really about. ```ts class Person { name: string; constructor(name: string) { this.name = name; } static species = "human"; } const p: Person = new Person("Ada"); // `Person` in a TYPE position = an instance const C = Person; // `Person` in a VALUE position = the constructor ``` The instance type `Person` has `name`. It does **not** have `species`, because static members live on the constructor object, not on instances. That is the whole static-side / instance-side split. ## What `typeof Person` gives you In a type position, `typeof <value>` is the **type query** operator: it asks the compiler for the type of an existing value. Applied to a class it yields the static side — a type that has the class's static members plus a construct signature describing how to `new` it. ```ts function make(ctor: typeof Person, name: string): Person { return new ctor(name); } make(Person, "Ada"); ``` This type query is a compile-time operator that happens to reuse the `typeof` keyword; it is not the runtime `typeof` expression, and it is erased along with everything else in the type layer. ## Writing the constructor type by hand You do not have to name a class to describe a constructor. A **construct signature** spells the shape out: ```ts function make(ctor: new (name: string) => Person, name: string): Person { return new ctor(name); } ``` `typeof Person` says "this exact class (or a subclass)", including its statics. `new (name: string) => Person` says "anything you can `new` with a string to get a Person" — a looser contract that also accepts an unrelated class or a class expression with the right shape. Prefer the construct signature when you want to accept several classes; prefer `typeof Person` when the callee also uses the statics. ## Why the original annotation failed `function make(ctor: Person)` demands an object with a `name: string` property. The class value has `species`, `prototype` and a construct signature, but no `name` in the instance sense, so the assignment is rejected. The error text names both sides — `typeof Person` on the left, `Person` on the right — and once you can read that pair, the fix is obvious. The mirrored mistake is just as common: annotating something `typeof Person` and then trying to read `.name` off it, or calling it without `new`. ## Going back the other way Given a constructor type, `InstanceType<T>` recovers the instance type, so `InstanceType<typeof Person>` is just `Person`. That round trip is mostly useful when the class has no exported name — for example a class expression stored in a `const`: ```ts const Point = class { x = 0; y = 0; }; type Point = InstanceType<typeof Point>; // the instance type now has a name ``` ## Why this matters beyond the annotation Factories, dependency-injection containers, plugin registries and test helpers all pass classes around as values. Every one of them has to decide whether the parameter means "the thing" or "the maker of the thing". Getting that wrong is the single most common TypeScript error when a class first crosses a function boundary — and none of it survives compilation, since the type layer is erased and only the ordinary JavaScript class value is emitted.