In TypeScript 5, a standard (TC39) method decorator returns a replacement function that is installed once on the prototype. So how do you use a decorator to give each instance its own bound copy of that method, and what exactly does `context.addInitializer` run and when?

## The problem ```typescript class Timer { count = 0; tick() { this.count += 1; } } const t = new Timer(); const detached = t.tick; detached(); // this is not the instance ``` The usual fix is a bound copy per instance. Can a method decorator do it? Its lever is the return value, and that replaces the function installed on the **prototype** — one function object shared by every instance. It has no instance to bind to, because at class-definition time none exists. So the return value is structurally the wrong tool. ## What `addInitializer` is Every standard decorator context exposes `addInitializer(fn)`. It does not change the decorated element; it schedules `fn` to run during initialization: - **non-static member decorator** — `fn` runs at the beginning of the constructor of every instance, with `this` bound to that instance. - **static member decorator** — `fn` runs once during class initialization, with `this` bound to the class. - **class decorator** — `fn` runs after the class has been fully defined, with `this` bound to the class. This is the natural place to register the class somewhere. A decorator may call it more than once, and may both call it and return a replacement. ## The auto-binding decorator ```typescript function bound(_target: Function, context: ClassMethodDecoratorContext) { const name = context.name; context.addInitializer(function (this: any) { this[name] = this[name].bind(this); }); } class Timer { count = 0; @bound tick() { this.count += 1; } } const t = new Timer(); const detached = t.tick; detached(); t.count; // 1 ``` The read `this[name]` finds the method on the prototype, `.bind(this)` produces a closure permanently tied to this instance, and the assignment creates an **own** property that shadows the prototype one. Note the decorator itself returns nothing: it changes nothing about the shared method. ## Four details that separate a correct answer from a vague one **1. `function`, not an arrow.** The callback's `this` is supplied by the runtime. An arrow captures the enclosing module scope's `this` instead — usually `undefined` — and the whole thing silently fails. Type it as `function (this: Timer)` or `function (this: any)` so the checker keeps you honest. **2. It runs before field initializers.** For a non-static member the callback fires at the *beginning* of the constructor, ahead of the class's own field initializers. In the example above, `count = 0` has not run yet when the binding happens — harmless there, but fatal if a callback tries to read a field: ```typescript context.addInitializer(function (this: Timer) { console.log(this.count); // undefined — count = 0 has not run yet }); ``` If you need post-construction state, arrange for the work to happen later — from a field initializer transform on a field declared after the ones you need, or from an explicit init method. **3. `context.name` may be a symbol, and the member may be private.** `this[name]` works for a string or symbol key, but for a `#`-private method there is no key to index with. Use `context.access.get(this)` to read it, and understand that you cannot then install a shadowing own property under a private name — auto-binding a private method is not expressible this way. **4. Throwing aborts construction.** An initializer that validates and throws prevents the instance from escaping, which is a legitimate use, but it means an unexpected error in a decorator's initializer surfaces as a constructor failure far from the decorator's source. ## When to prefer the returned replacement instead Use the return value when the behaviour is genuinely per-class and stateless: logging, timing, memoizing on a key derived from arguments, argument coercion. Use `addInitializer` when the behaviour needs the instance: binding, per-instance caches, registering the instance with an observer, seeding per-instance state through `context.access.set`. Many real decorators do both — return a wrapper *and* register an initializer. ## The cost of auto-binding Binding per instance allocates one function object per decorated method per instance, and moves the method off the prototype for that object, so the shared version is no longer what `obj.tick` resolves to. In a class instantiated in the thousands that is measurable. The alternative — declaring the member as an arrow-function field, or binding explicitly at the point where the method is detached — costs nothing at the decorator level and is often the better default, with the decorator reserved for the cases where call sites cannot be changed.