A TypeScript service uses experimentalDecorators and emitDecoratorMetadata, and its DI container resolves constructor dependencies from design:paramtypes. One parameter is typed as an interface and the container fails to resolve it. Why does the metadata record `Object` there, and how do you make that dependency injectable?

## The mechanism, restated precisely With `experimentalDecorators` and `emitDecoratorMetadata` on, a decorated class gets a `design:paramtypes` entry holding an array of runtime values, one per constructor parameter. The compiler builds that array by *serialising* each declared parameter type: it emits a reference to whatever value corresponds to the type. The rule is simple and brutal. If the type is a class, the value is that class's constructor. If it is `string`, `number`, or `boolean`, the value is `String`, `Number`, or `Boolean`. If it is an array type, the value is `Array`. For everything else — an interface, a type alias for an object literal shape, a union of unrelated types, `any`, `unknown`, a bare type parameter — there is nothing in the running program to reference, and the compiler emits `Object`. ```typescript import "reflect-metadata"; interface Logger { log(msg: string): void; } class Clock { now() { return new Date(); } } function Injectable(): ClassDecorator { return () => {}; } @Injectable() class Service { constructor(private logger: Logger, private clock: Clock) {} } const types: Function[] = Reflect.getMetadata("design:paramtypes", Service); console.log(types.map((t) => t.name)); // [ "Object", "Clock" ] ``` ## Why the container fails the way it does A metadata-driven container uses each entry as a lookup key. `Clock` is a fine key — you registered a provider under that class. `Object` is not: it is not a thing anyone registers, and worse, *every* unrepresentable parameter in the whole application serialises to the same `Object`, so the key is not even unique. The container reports something like "cannot resolve parameter 0", and the cause is a type-level fact (interfaces are erased) surfacing as a runtime configuration error. This is the single most instructive consequence of erasure in a decorator codebase, which is why it is asked. The candidate who says "interfaces do not exist at runtime" has the answer; the candidate who starts editing container configuration does not. ## Generics lose their arguments too A related trap: a parameter typed `Repository<User>` does *not* serialise to `Object`. It serialises to the `Repository` constructor, with the type argument dropped, because the compiler serialises the type *reference* and generics are erased. So a container asked for `Repository<User>` and one asked for `Repository<Post>` see the identical token and get the identical provider. Frameworks work around this with an explicit token per entity rather than trying to recover the type argument, because the information genuinely is not there. ## Fix one: depend on a class Replace the interface with a class — often an abstract class that declares the contract and is never instantiated directly: ```typescript abstract class Logger { abstract log(msg: string): void; } class ConsoleLogger extends Logger { log(msg: string) { console.log(msg); } } ``` Now `design:paramtypes` records `Logger`, a real constructor, and the container registers `ConsoleLogger` as the provider for the `Logger` token. You keep a compile-time contract and gain a runtime identity. The price is that the abstraction is now a class in your emitted bundle rather than free type-level structure, and consumers who wanted structural typing must actually extend it. ## Fix two: an explicit token Keep the interface and stop relying on serialisation. Declare a token — a unique symbol or a const string — register the provider under it, and annotate the parameter with a decorator that records the token in its own metadata (`@Inject(LOGGER)` in the frameworks that spell it that way). A container always prefers an explicit token over the serialised type, so the `Object` entry becomes irrelevant. This is the only option for dependencies with no class at all: a config object, a connection string, a feature-flag map. It also makes the wiring visible at the call site, which is a readability gain some teams prefer even where a class would work. ## The judgment to bring The framing that lands in an interview is: *metadata-driven DI can only be as precise as the type serialisation, and the serialisation is deliberately shallow.* Design your dependency graph around types that have runtime identity, and use explicit tokens the moment they do not. Treat "my interface dependency will not inject" as a design signal, not a bug to configure around — and be aware that this whole mechanism is confined to the `experimentalDecorators` world, since standard decorators receive no `design:paramtypes` at all.