Your team's shared library exposes functions that consumers frequently pass around as callbacks. How far can TypeScript's `this` typing guarantee those functions get the receiver they expect, and where does that guarantee stop?

principalshould knowfreq 20%

answer

checks at the boundary only
erased, so nothing runs
any, assertions, foreign invokers
this: void as the safe export
make the receiver irrelevant

basics

~20 s

TypeScript can reject call sites and assignments it can see, using declared this parameters. It cannot guarantee anything at runtime: the annotations are erased, so any untyped caller, assertion, or third-party invoker can still supply the wrong receiver. Design so the receiver does not matter.

solid answer

~50 s

The type layer gives you exactly one thing: errors at call sites and assignments the compiler checks. Declaring this: Widget on a method makes a detached call an error and makes assigning that method to a this: void callback type an error, which is the real value for a callback-heavy API. Everything past the compiler's view is unprotected — the annotation is erased, so an any-typed caller, an assertion, plain JavaScript, or a third-party invoker that calls your function with whatever receiver it chooses will all sail through and fail at runtime. The design conclusion follows: for a shared library, prefer functions that never read this at all and mark them this: void so a receiver-dependent method cannot be passed where a free function is expected. Reserve this parameters for the cases where you are modelling an existing convention you cannot change, and treat them as enforced documentation rather than a guarantee.

The type layer gives you exactly one thing: errors at call sites and assignments the compiler checks. Declaring `this: Widget` on a method makes a detached call an error and makes assigning that method to a `this: void` callback type an error, which is the real value for a callback-heavy API. Everything past the compiler's view is unprotected — the annotation is erased, so an `any`-typed caller, an assertion, plain JavaScript, or a third-party invoker that calls your function with whatever receiver it chooses will all sail through and fail at runtime. The design conclusion follows: for a shared library, prefer functions that never read `this` at all and mark them `this: void` so a receiver-dependent method cannot be passed where a free function is expected. Reserve `this` parameters for the cases where you are modelling an existing convention you cannot change, and treat them as enforced documentation rather than a guarantee.

code

typescript · 19 lines

typescript

type ClickHandler = (this: void, event: { x: number; y: number }) => void;

class Tracker {
  count = 0;

  // declaring the receiver marks this method as attachment-dependent
  record(this: Tracker, event: { x: number; y: number }): void {
    this.count += event.x + event.y;
  }
}

const tracker = new Tracker();

// @ts-expect-error 'this' of type 'Tracker' is not assignable to 'this' of type 'void'
const bad: ClickHandler = tracker.record;

const good: ClickHandler = (event) => tracker.record(event);
good({ x: 1, y: 2 });
console.log(tracker.count); // 3

go deeper

for a junior

Know the headline: these annotations produce compile errors only. Nothing about them survives into the running JavaScript, so a wrong receiver at runtime is still possible.

for a middle

List what the compiler does catch — detached calls, assignment to a receiver-free callback type, and the receiver argument of call/apply/bind under the matching strict flag — and be able to name a case each check misses.

for a senior

Walk through the concrete holes on a real boundary: any-typed consumers, assertions, plain JavaScript callers, foreign invokers, and string-keyed dispatch. Then say how you would shape the exported surface so those holes cannot be reached.

for a principal

Own the API decision and the rollout. Argue for exports that never depend on a receiver, this: void as the cheap enforcement of that policy, this parameters reserved for conventions you inherited, and be explicit about the false-confidence failure mode this creates in a team.

What the compiler will actually catch

Start with the honest inventory. With this parameters declared, TypeScript catches:

Detached calls it can see. const f = obj.method; f(); fails because the receiver at a bare call is typed void, which is not assignable to the declared type.
Assignments between function types. A method declaring this: Tracker is not assignable to a parameter typed (this: void, e: Event) => void. This is the mechanism a library uses to say "I invoke this callback without a useful receiver", and it is the highest-value check for a callback-heavy API.
Explicit call forms, under strictBindCallApply. With that flag on, the standard library types call, apply and bind so the receiver argument is checked against the function's declared this type, rather than being accepted as anything.

With noImplicitThis on, you also get a nag whenever a function reads this without a knowable receiver — which is what pushes authors to declare one in the first place.

Where the guarantee ends

Every one of those checks is compile-time and local. Nothing is emitted, so nothing is verified when the code runs. The holes are concrete:

Untyped or any-typed callers. Anything typed any can call your function however it likes. Plain JavaScript consumers, or TypeScript consumers with skipLibCheck-shaped blind spots and any at the boundary, get no checking at all.
Assertions. An as cast is a claim the checker accepts without evidence; casting a receiver-dependent function to a plain function type erases the requirement instantly.
Third-party invokers. A scheduler, an event system, a template engine or an RPC layer decides the receiver at call time. Your declaration expresses what you need; it has no influence over what they do.
Data-driven dispatch. Anything that looks a function up by string key and calls it has already left the part of the program the checker models.

So the accurate framing for a review or a design doc is: this parameters are documentation the compiler enforces within your own boundary, in the same family as any other type — real value inside, zero authority outside.

The design conclusion for a shared library

Given that, the strongest position is to make the receiver irrelevant:

Prefer free functions that take their context as an ordinary parameter. format(config, cents) needs no receiver, cannot be broken by detachment, survives every boundary, and is trivial to test. This is the default answer.
Mark genuinely receiver-free exports this: void. It costs nothing, documents the intent, and turns "someone attached this to an object and it started reading this" into a compile error.
Reserve this parameters for conventions you do not control — an existing options-object API, a legacy plugin surface, declaration files for an older library that invokes callbacks with a meaningful receiver. There the annotation is worth writing because it matches reality.
If a receiver-dependent method must cross a boundary, fix the receiver at the boundary rather than hoping callers get it right, and let the resulting type say so — a wrapper that takes the function plus its context and returns a function with the requirement removed is the shape that communicates it.

Talking about the runtime side without overreaching

Candidates often jump straight to "just use an arrow function" or "bind it in the constructor". Those are real fixes, but they are JavaScript binding decisions with their own tradeoffs — per-instance function identity, interaction with prototypes and overriding — and they belong to the runtime discussion, not the type one. In a type-layer answer, the point to make is that the type system cannot tell you whether the binding actually happened: whichever runtime approach you choose, the annotation only records the expectation.

What a strong answer sounds like

A senior answer inventories the checks and the holes. A principal answer goes one step further and treats it as an API-surface decision: given that the guarantee cannot cross the boundary, the library should be shaped so that no consumer can get it wrong in the first place, with this typing used to enforce that shape internally and to interoperate with conventions the team did not choose. The failure mode to name explicitly is a team that adds this parameters everywhere, believes the problem is solved, and is then surprised by a production failure originating in an untyped consumer.

## What the compiler will actually catch Start with the honest inventory. With `this` parameters declared, TypeScript catches: 1. **Detached calls it can see.** `const f = obj.method; f();` fails because the receiver at a bare call is typed `void`, which is not assignable to the declared type. 2. **Assignments between function types.** A method declaring `this: Tracker` is not assignable to a parameter typed `(this: void, e: Event) => void`. This is the mechanism a library uses to say "I invoke this callback without a useful receiver", and it is the highest-value check for a callback-heavy API. 3. **Explicit call forms, under `strictBindCallApply`.** With that flag on, the standard library types `call`, `apply` and `bind` so the receiver argument is checked against the function's declared `this` type, rather than being accepted as anything. With `noImplicitThis` on, you also get a nag whenever a function reads `this` without a knowable receiver — which is what pushes authors to declare one in the first place. ## Where the guarantee ends Every one of those checks is compile-time and local. Nothing is emitted, so nothing is verified when the code runs. The holes are concrete: - **Untyped or `any`-typed callers.** Anything typed `any` can call your function however it likes. Plain JavaScript consumers, or TypeScript consumers with `skipLibCheck`-shaped blind spots and `any` at the boundary, get no checking at all. - **Assertions.** An `as` cast is a claim the checker accepts without evidence; casting a receiver-dependent function to a plain function type erases the requirement instantly. - **Third-party invokers.** A scheduler, an event system, a template engine or an RPC layer decides the receiver at call time. Your declaration expresses what you *need*; it has no influence over what they *do*. - **Data-driven dispatch.** Anything that looks a function up by string key and calls it has already left the part of the program the checker models. So the accurate framing for a review or a design doc is: `this` parameters are documentation the compiler enforces *within your own boundary*, in the same family as any other type — real value inside, zero authority outside. ## The design conclusion for a shared library Given that, the strongest position is to make the receiver irrelevant: - **Prefer free functions that take their context as an ordinary parameter.** `format(config, cents)` needs no receiver, cannot be broken by detachment, survives every boundary, and is trivial to test. This is the default answer. - **Mark genuinely receiver-free exports `this: void`.** It costs nothing, documents the intent, and turns "someone attached this to an object and it started reading `this`" into a compile error. - **Reserve `this` parameters for conventions you do not control** — an existing options-object API, a legacy plugin surface, declaration files for an older library that invokes callbacks with a meaningful receiver. There the annotation is worth writing because it matches reality. - **If a receiver-dependent method must cross a boundary, fix the receiver at the boundary** rather than hoping callers get it right, and let the resulting type say so — a wrapper that takes the function plus its context and returns a function with the requirement removed is the shape that communicates it. ## Talking about the runtime side without overreaching Candidates often jump straight to "just use an arrow function" or "bind it in the constructor". Those are real fixes, but they are JavaScript binding decisions with their own tradeoffs — per-instance function identity, interaction with prototypes and overriding — and they belong to the runtime discussion, not the type one. In a type-layer answer, the point to make is that the *type system cannot tell you whether the binding actually happened*: whichever runtime approach you choose, the annotation only records the expectation. ## What a strong answer sounds like A senior answer inventories the checks and the holes. A principal answer goes one step further and treats it as an API-surface decision: given that the guarantee cannot cross the boundary, the library should be shaped so that no consumer can get it wrong in the first place, with `this` typing used to enforce that shape internally and to interoperate with conventions the team did not choose. The failure mode to name explicitly is a team that adds `this` parameters everywhere, believes the problem is solved, and is then surprised by a production failure originating in an untyped consumer.

A teammate says adding `this` parameters across the library makes the callback problem impossible. How do you respond?
It makes it impossible *inside the compiler's view*. The annotations are erased, so an `any`-typed caller, an `as` assertion, a JavaScript consumer or any third-party invoker can still supply the wrong receiver and fail at runtime. It is enforced documentation at our own boundary, not a guarantee — the durable fix is exporting functions that do not depend on a receiver.
What does `strictBindCallApply` add to this picture?
With it enabled, the standard library types `call`, `apply` and `bind` so the receiver argument is checked against the function's declared `this` type instead of being accepted loosely. That closes the explicit-call-form hole for code the compiler can see, but it changes nothing for callers outside the type system.
When would you still declare a `this` parameter rather than passing context as an argument?
When you are modelling a convention you do not own — an existing options-object API, a legacy plugin surface, or a declaration file for a library that genuinely invokes callbacks with a meaningful receiver. There the annotation matches reality and helps consumers. For a new API you control, an ordinary parameter is the simpler and safer design.
How would you stage this across a large existing codebase?
Turn on the strict-family checking so unknown receivers surface, then triage by boundary rather than by file: annotate or reshape the exported surface first, since that is where wrong receivers actually arrive, and leave internal call sites to the general strictness rollout. Reshaping high-traffic exports to take context as a parameter usually retires more risk than annotating them does.

saying these in an interview costs you the question

Claims this parameters protect against wrong receivers at runtime
Forgets that an as assertion discards the requirement entirely
Assumes third-party invokers respect the declared receiver
Treats noImplicitThis as a guarantee rather than a nag
Never considers making the receiver irrelevant to the API

Your team's shared library exposes functions that consumers frequently pass around as callbacks. How far can TypeScript's `this` typing guarantee those functions get the receiver they expect, and where does that guarantee stop?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the compiler will actually catch

Where the guarantee ends

The design conclusion for a shared library

Talking about the runtime side without overreaching

What a strong answer sounds like

▾common follow-ups4 questions

▾red flags5 flags

§ context

▾related questions5 questions

▾related topics3 topics

What the compiler will actually catch

Where the guarantee ends

The design conclusion for a shared library

Talking about the runtime side without overreaching

What a strong answer sounds like

answer

go deeper

context