In a TypeScript codebase, when is a decorator the right tool for something like dependency wiring, validation, or caching — and what does choosing a decorator cost you compared with a plain function or an explicit configuration object?

## Two different jobs get called "decorator" It clarifies the whole discussion to split them. **Declarative marking.** `@Column`, `@Entity`, `@IsEmail`, `@Get("/users")`. The decorator records a fact and changes nothing about how the code runs. A generic runtime reads the accumulated facts later and does the work. **Behavioural wrapping.** `@Memoize`, `@Retry(3)`, `@LogCalls`. The decorator replaces or wraps the thing it decorates, so calling the method now does something different from what its body says. These have very different cost profiles, and conflating them is where teams get into trouble. ## Where marking earns its place Marking is strongest when three things hold. The fact is *about* the member, so putting it anywhere else invites drift — a separate mapping file that still says `title` after the field was renamed to `heading` is a real and common bug, and the decorator makes that impossible. The fact is consumed by *generic* machinery that must discover it by reflection, not by a specific caller. And there is roughly one such fact per member, so the declaration stays short. When those hold, the alternative — a central schema object — buys you a different set of properties that are sometimes better: the whole model is visible in one place, it is data you can generate or diff, and it requires no build configuration. Schema-first libraries make exactly this trade, and derive the static type *from* the schema so there is only one declaration rather than two that can disagree. ## Where wrapping usually loses Behavioural decorators read beautifully and debug badly. The method body in front of you is not what runs. A stack trace goes through a wrapper you did not write. A test that calls the method exercises the caching too, so you need a way to turn it off. And with the legacy decorator form the *type* is untouched: if the decorator changes the method's effective signature, or adds members to the class, the checker still sees the original declaration and callers get no help. A plain higher-order function costs one extra line at the definition site and removes every one of those problems: ```typescript const getUser = memoize(async (id: string) => fetchUser(id)); ``` The wrapping is visible, the type flows through the function's own generics, and there is nothing to configure. Reach for a behavioural decorator when the framework already owns the call — an interceptor pipeline that will apply it uniformly — not to hand-decorate scattered methods. ## The costs to name explicitly in an interview **Build coupling.** Legacy decorators need `experimentalDecorators`; metadata-driven wiring adds `emitDecoratorMetadata` and a `reflect-metadata` import. That emit requires the type checker, so a transpiler swap can silently degrade it. Standard decorators are cleaner here but give you no type metadata at all. **Module-load side effects.** Decorators run when the class body evaluates. If the module is never imported, nothing registers — which is why frameworks need explicit module lists or glob loading, and why bundlers cannot easily tree-shake a decorated class: the decorator call is a side effect the bundler must assume matters. **Testability.** A class whose behaviour lives in decorators cannot be fully exercised by `new Thing()`; you need the container, the polyfill, or the interceptor chain. That pushes unit tests toward integration tests, which is a real ongoing tax. **Type invisibility.** With the legacy form the declared type is what you wrote, full stop. Runtime additions are unseen by callers, and the mismatch is discovered at runtime. **Cognitive surface.** Every decorator is vocabulary a new engineer must learn before they can read a class, and the metadata object on a class is effectively a shared public namespace that several libraries may write into. ## How I would decide Ask who consumes the fact. If a *generic* runtime discovers it reflectively and the fact is inherently per-member, a decorator is the right shape. If a *specific* caller uses it, pass it as an argument — a decorator is an over-general answer to a direct question. Then ask what the failure looks like when the wiring is wrong. Decorator-driven systems fail late and vaguely: an unresolved token at request time rather than a compile error. Where that is unacceptable, prefer explicit construction, or at minimum validate the whole object graph at startup so the failure moves to boot. Finally, decide once, at the codebase level, rather than per feature. Mixed idioms — some services wired by decorators, some by a factory — cost more than either choice would alone.