What is `new.target` inside a JavaScript function, and how do you use it to guard a constructor against being called without `new`?

## What `new.target` is `new.target` is a *meta-property* — a fixed piece of syntax, not a normal property lookup on an object called `new`. You can read it inside a function body (including a class constructor) and it tells you which constructor, if any, drove the current invocation. It is only meaningful inside a function or constructor body; there is nothing sensible for it to mean at the top level of a script. The values you will see: - **`undefined`** — the function was invoked as a plain call: `Dog('Rex')`, `dog.method()`, `fn.call(obj)`, `arr.map(fn)`. - **the constructor** — the function was constructed: inside `new Dog('Rex')`, `new.target` is `Dog`. - **a subclass** — in a class hierarchy, the constructor the caller actually named. Constructing `new Circle()` where `class Circle extends Shape` makes `new.target` equal `Circle` inside *both* constructors, because the value propagates down the `super()` chain rather than being reset to the class you are lexically inside. ```js function probe() { return new.target; } probe(); // undefined new probe(); // [Function: probe] ``` ## Guard 1: reject the mistake The defensive form makes a forgotten keyword impossible to miss: ```js function Dog(name) { if (!new.target) { throw new TypeError("Dog must be called with new"); } this.name = name; } ``` The payoff is locality. Without the guard, a forgotten `new` in sloppy code writes a property onto the global object and hands back `undefined`, and the program fails somewhere else entirely; with it, the stack trace points at the caller who made the mistake. This is what a `class` constructor does for you automatically — the guard is how you get the same protection out of a plain function. ## Guard 2: construct anyway The forgiving form makes the keyword optional, an idiom older APIs used so that both call styles work: ```js function Dog(name) { if (!new.target) return new Dog(name); this.name = name; } Dog('Rex') instanceof Dog; // true new Dog('Rex') instanceof Dog; // true ``` It is convenient, and it costs you something: the API no longer teaches callers which style it wants, and the auto-construct branch has to forward every argument, which is easy to get wrong when the signature grows. Prefer the throwing guard in new code unless you have a specific reason to accept both. ## Guard 3: an abstract base Because `new.target` names the constructor the caller invoked rather than the one you are inside, a base can detect direct instantiation: ```js class Shape { constructor() { if (new.target === Shape) { throw new TypeError("Shape is abstract; construct a subclass"); } } } class Circle extends Shape {} new Circle(); // fine — new.target is Circle new Shape(); // TypeError ``` JavaScript has no `abstract` keyword, so this comparison is the standard way to express the constraint. The same trick supports registries and diagnostics: a base can log or record `new.target.name` to know which concrete type was built. ## Arrow functions An arrow function has no `new.target` binding of its own, exactly as it has no `this` of its own. Reading `new.target` inside an arrow gives whatever the enclosing ordinary function's value is. That is usually what you want — a helper arrow defined inside a constructor still reports the constructor — but it means an arrow cannot be used as the guarded function itself. ## Why it beats the older heuristics Before `new.target`, the common test was whether the receiver looked like an instance of the constructor. That test answers a different question — it inspects the prototype chain of whatever `this` happens to be — so it is fooled in both directions: an ordinary call whose receiver was deliberately set to an existing instance passes the check even though nothing was constructed, and a legitimately constructed object whose prototype was reassigned can fail it. `new.target` asks the runtime directly how the function was invoked, which is the question you actually meant. ## Practical notes A guard costs one comparison per construction, which is noise next to the object allocation, so there is no real performance argument against it. Put it on the first line so it runs before any side effect. And be honest about scope: the guard protects against a forgotten keyword, not against a caller who deliberately invokes the internal construct behaviour through other means.