You own a widely used TypeScript library whose public types declare dozens of callback members. How do you decide between method shorthand and the property function-type form across that surface, and what does each choice commit you to?

## The decision, restated Every function-valued member in your published types is declared one of two ways: ```ts interface Options { onEvent(e: Event): void; // method shorthand — bivariant parameters onEvent2: (e: Event) => void; // property function type — contravariant under strict } ``` They emit nothing and describe the same call shape. What differs is how strictly the compiler checks what your consumers write, and — because the *declared* type is what decides — that strictness is your choice to make on their behalf, not theirs. ## Default: property form for anything the consumer supplies When a consumer passes you a handler, your type is a contract about what *you* may call it with. Under the property form, `strictFunctionTypes` enforces that contract: a consumer who writes `onEvent: (e: MouseEvent) => {}` against a declared `Event` parameter gets an error at the line they wrote, with their own names in the message. Under method shorthand the same code compiles, your library dispatches a `KeyboardEvent` into it, and the failure arrives as an `undefined` property somewhere unrelated. That difference — error at the definition site versus a mystery at runtime — is the whole argument. ## Where method shorthand still earns its place Two cases: 1. **Container-like and generic types.** If your interface is `Collection<T>` with `add(item: T): void` and `contains(item: T): boolean`, the honest structural answer is invariance in `T`, and invariance makes the type painful to pass around. Method shorthand keeps `Collection<Dog>` usable where `Collection<Animal>` is expected — the same bargain the standard library makes with `Array<T>`. 2. **Broad contracts with intentionally varying implementations.** Visitor- and plugin-shaped interfaces that many outside types satisfy, where implementers legitimately handle a narrower case and you have another mechanism (a discriminant, a registration key) that actually guarantees the right value arrives. In both cases you are choosing to trust the implementer. Say so in the docs. ## The evolution commitment This is the part that separates a policy from a preference. Consider widening a published parameter from `MouseEvent` to `Event`, a normal thing to do when a callback gains new call sites. - **Property form:** every consumer handler typed to the old narrow parameter now fails to compile. That is a **breaking change** in the semver sense, and it should be — those handlers really cannot cope with the new inputs. You ship it in a major, with a migration note. - **Method shorthand:** nothing breaks at compile time. Consumers upgrade in a patch release and their handlers start receiving events they were never written for. You have converted a compile break into a distributed, hard-to-attribute runtime bug in code you do not own. The property form does not create the breakage; it *reveals* it. A library whose types cannot express that a change is breaking will make its users pay for it later. Some changes are non-breaking under both forms and worth knowing: **adding** a parameter to a callback you invoke is safe, because a function that accepts fewer parameters is assignable to one that accepts more — consumers simply ignore the new argument. **Narrowing** a parameter is the mirror case and is safe under the property form. ## Making the policy stick A mixed surface is the worst outcome: consumers cannot predict which members check strictly, and neither can your own contributors. Pick a default, write it into the contribution guide with the one-sentence reason, and enforce it mechanically — the `@typescript-eslint/method-signature-style` rule exists exactly to pin one form across a codebase, with escape comments for the container-like exceptions. Migrating an existing surface is mostly mechanical, but expect the switch to the property form to surface real consumer errors on the first release that ships it; budget that as part of the change rather than reverting when the first bug report arrives. ## What to say in the interview Name the mechanism (bivariant methods versus contravariant function types), state a default with a reason, name the exception class, and — the part most candidates miss — connect it to release policy: the declaration form decides whether your future parameter changes are enforceable at compile time or merely hoped for.