The exact error Nest throws and what position 0 means

Nest throws Error: Nest can't resolve dependencies of the UsersService (?). Please make sure that the argument dependency at index [0] is available in the AppModule context the moment you flip emitDecoratorMetadata: false in tsconfig on TypeScript 5.5. The lone question mark is literal: it marks the first constructor argument whose design:paramtypes metadata the compiler no longer emits, leaving Nest’s reflect-metadata lookup empty at bootstrap.

Error: Nest can't resolve dependencies of the UsersService (?). Please make sure that the argument dependency at index [0] is available in the AppModule context.

That lone question mark is not a formatting glitch. It is the literal string Nest inserts where it would normally print a class name. The DI container asked the reflect-metadata registry for the constructor parameter types of UsersService, got undefined back for index 0, and wrote “?” because it has nothing else to print. Position 0 is the first constructor argument — whatever you wrote immediately after the opening parenthesis of constructor(.

Before TypeScript 5.5 this rarely surfaced. The moment a team flips "emitDecoratorMetadata": false in tsconfig.json, every Nest provider that relied on automatic type inference starts failing with this exact message. The usual triggers are a migration toward Stage 3 decorators, a switch to a transpile-only build, or a Vite or SWC pipeline that silently drops the flag.

The screenshot lands on the TypeScript compiler options page at typescriptlang.org/tsconfig/#emitDecoratorMetadata. The paragraph visible under the heading explains that the flag emits design:type, design:paramtypes, and design:returntype metadata for decorated declarations, and the warning panel next to it reminds readers that the flag only does anything when experimentalDecorators is also on. The embedded code sample shows a class with a constructor taking a Foo parameter and the compiled JavaScript output with a Reflect.metadata("design:paramtypes", [Foo]) call inserted above the class definition. That second emitted call is exactly what Nest reads at bootstrap. Turn the flag off and that line disappears from the compiled JS, which is why index 0 becomes “?”.

Why Nest’s injector collapses without design:paramtypes

Nest’s DI container sits on top of the reflect-metadata polyfill. When you register a provider, Nest walks the class, calls Reflect.getMetadata("design:paramtypes", TargetClass), and treats the returned array of constructor types as injection tokens. The lookup is synchronous and runs during module bootstrap, before any HTTP handler is mounted.

That metadata array is produced by the TypeScript compiler, not by Nest. When emitDecoratorMetadata is false, the compiler skips the emit entirely — there is no fallback, no inference, nothing. Reflect.getMetadata returns undefined, Nest iterates an empty list, and every constructor parameter is left unresolved. You will see nest question mark index emitdecoratormetadata errors for every provider that used implicit type-based injection — one per class, in roughly the order Nest tries to instantiate them.

More detail in build pipeline quirks.

The version matrix matters here. Nest 10.x, the current stable line as of April 2026, still ships on the legacy experimental decorators spec. The framework has not migrated to Stage 3 decorators, and the roadmap in the nestjs/nest repo tracks this as a future effort rather than a near-term release. If you are on @nestjs/core 10.3 or 10.4 with TypeScript 5.5, you are firmly in legacy-decorator territory — both experimentalDecorators and emitDecoratorMetadata must stay on for implicit injection to work.

TypeScript 5.5 changed the decorator emit rules

TS 5.0 introduced Stage 3 decorators. TS 5.5 tightened emit rules further and produced clearer error messages when the two decorator modes collide, which is why this failure became more visible this cycle. Stage 3 decorators do not support the reflect-metadata bridge at all — by design. The TC39 proposal explicitly skips runtime type information because the committee wanted a decorator spec that did not depend on TypeScript-specific semantics.

Practically, this leaves three combinations:

Background on this in TypeScript decorators in 2026.

• experimentalDecorators: true + emitDecoratorMetadata: true — legacy mode. Nest works out of the box.
• experimentalDecorators: true + emitDecoratorMetadata: false — legacy decorators, but no design:paramtypes. This is where the “?” at index 0 error lives.
• experimentalDecorators: false — Stage 3 decorators, no metadata bridge. Incompatible with Nest’s current DI model. You will see errors about missing Reflect.decorate or unexpected decorator syntax.

Only the first combination is supported for Nest 10 today. If you need Stage 3 decorators for another reason — a library that ships them, a policy from a shared TC39 migration working group — you have to wait for Nest to cut the cord, which the core team has signalled is tied to a future major release.

Purpose-built diagram for this article — Nest Can’t Resolve Dependencies ‘?’ at Index 0 After Disabling emitDecoratorMetadata on TS 5.5.

The diagram traces the path from a source users.service.ts file down through tsc --emitDecoratorMetadata into the compiled dist/users.service.js, where an arrow points at the injected __metadata("design:paramtypes", [UsersRepository]) call sitting just above the class declaration. A second branch shows the same source compiled with the flag off, and at the bottom a red node labelled Reflect.getMetadata → undefined feeds into the Nest injector, which in turn emits the “Nest can’t resolve dependencies” line. The flow makes clear that the break happens at compile time, not at runtime — by the time Nest asks for the metadata, the answer has already been decided minutes earlier by the TypeScript invocation you ran.

Fixing the error with explicit tokens

There are two working fixes. The first and fastest is to put emitDecoratorMetadata back to true. If you disabled it for speed or because a SWC config inherited a cleaner template from a frontend project, flipping it back costs you almost nothing on modern compilers.

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "target": "ES2022",
    "module": "NodeNext"
  }
}

If you are on SWC via @swc/core 1.4+, the equivalent lives in .swcrc:

I wrote about explicit type tokens if you want to dig deeper.

{
  "jsc": {
    "parser": { "syntax": "typescript", "decorators": true },
    "transform": { "legacyDecorator": true, "decoratorMetadata": true }
  }
}

The second fix — appropriate when you genuinely want the metadata emit off, for build-size reasons or because you are shipping a library consumed by Stage 3 users — is to replace every implicit injection with an explicit @Inject() call. Nest uses the token you pass to @Inject as the lookup key, sidestepping the reflect-metadata path entirely:

import { Inject, Injectable, Logger } from '@nestjs/common';
import { UsersRepository } from './users.repository';

@Injectable()
export class UsersService {
  constructor(
    @Inject(UsersRepository) private readonly repo: UsersRepository,
    @Inject(Logger) private readonly logger: Logger,
  ) {}
}

With @Inject(UsersRepository), Nest no longer needs to know the TypeScript type of the parameter. It reads the token off the custom metadata slot the decorator wrote and resolves from there. The “?” disappears because there is now a concrete identifier in its place.

This is also how you inject anything that is not a class — string tokens, symbols, config values, async factories. Those cases always needed @Inject even when emitDecoratorMetadata was on, because TypeScript has no design-time representation for a value-level token.

Benchmark results for Nest DI Resolution Time: emitDecoratorMetadata vs Explicit @Inject.

The bar chart plots cold-start module resolution times measured across three configurations of a Nest 10.3 app with 48 providers. The first bar, labelled “emitDecoratorMetadata on”, sits around 38 milliseconds for full module compile. The second, “explicit @Inject”, lands at roughly 31 milliseconds — a small but repeatable win because Nest skips the Reflect.getMetadata call for each parameter. The third bar is the broken state: “emitDecoratorMetadata off, no @Inject”, which does not complete at all and instead throws at the 4 ms mark when the first unresolved constructor blows up. The practical read is that explicit injection is marginally faster than implicit, so if performance is the reason you are considering this migration, the delta is too small to justify the refactor on its own.

Diagnosing the specific index number Nest prints

When Nest reports index [2] instead of index [0], you can skip straight to the third constructor argument. Nest counts from zero, matches the position it failed on, and prints that exact number. This is handy in classes with five or six dependencies where only one is broken — perhaps you injected a custom token with @Inject('CONFIG_TOKEN') at position 0, a typed service at position 1 which still resolves, and then another untyped parameter at position 2 where the design:paramtypes entry came back as Object instead of the real class.

A quick diagnostic is to add --verbose to the Nest CLI or check the full stack for the module name. The error message template reads:

Error: Nest can't resolve dependencies of the [ClassName] ([arg0], [arg1], ?). 
Please make sure that the argument [ArgType] at index [N] is available in the [ModuleName] context.

Anything printed as its class name resolved correctly. The “?” marks the exact slot that came back undefined. If you see two or three “?” entries in the same line, you have multiple untyped parameters in one constructor — fix them together rather than one at a time, because the next bootstrap attempt will just surface the second one.

One more trap: circular imports. If users.service.ts imports auth.service.ts which imports back, the TypeScript compiler can emit Object instead of the real class in the design:paramtypes slot, and Nest prints the nest question mark index emitdecoratormetadata error even though the flag is on. The fix there is forwardRef(() => AuthService), not a tsconfig change.

The Reddit thread list ranks the top posts from r/Nestjs_framework and r/typescript over the last twelve months tagged with variations of this error. The top-voted thread, titled “Nest DI suddenly breaks after upgrading to TS 5.5”, shows 312 upvotes and a pinned reply from a maintainer confirming that emitDecoratorMetadata is still required. The second thread discusses a SWC-based build where the flag was silently dropped by a .swcrc copied from a Vite template. The third is a migration question from an Angular team moving onto Nest and being caught off guard by the same tsconfig coupling. All three conversations arrive at the same fix: turn the flag back on or adopt explicit @Inject, matching the guidance in the official Nest custom providers documentation.

When disabling emitDecoratorMetadata is defensible

Most Nest apps should leave the flag on. The emit overhead is negligible, type-based injection is ergonomic, and every community example assumes the default. Three situations justify disabling it:

First, a shared library that also ships Stage 3 decorators for consumers on newer TypeScript configurations. In that case the library entry point should not depend on legacy metadata at all, and every @Injectable should carry @Inject tokens so the package keeps working regardless of the consumer’s tsconfig.

I wrote about tsconfig is probably wrong if you want to dig deeper.

Second, a build pipeline using a transpiler that cannot emit the metadata — some Bun configurations, older esbuild versions before 0.20, or Vite plugins that have not wired up the decorator metadata transform. If you are stuck on one of those, switching to explicit injection sidesteps the issue without blocking the migration.

Third, bundle-size concerns for browser output. Nest itself is server-side, but if you are packaging a shared domain module used by both a Nest backend and an Angular or React frontend, the decorator metadata calls bloat the browser bundle. Stripping them there and relying on explicit tokens keeps the shared package lean.

Outside those cases, the payoff does not justify the churn. Turning emitDecoratorMetadata back on is a one-line tsconfig change. Rewriting every constructor across a large codebase to use @Inject is a multi-day refactor that earns you a few milliseconds of cold-start time and a mild increase in type-declaration verbosity. If the nest question mark index emitdecoratormetadata error is the only reason you landed here, put the flag back and move on.

• TypeScript compiler reference — emitDecoratorMetadata: official description of what metadata the flag emits and when.
• NestJS documentation — custom providers and @Inject(): canonical guidance on explicit injection tokens.
• TC39 decorators proposal: the Stage 3 spec Nest has not yet adopted.
• nestjs/nest on GitHub: core framework repository, release notes, and open issues tracking decorator migration.
• SWC configuration — legacyDecorator and decoratorMetadata: how to preserve the metadata emit when SWC replaces tsc.

Common questions

What does the ‘?’ at index 0 mean in a Nest can’t resolve dependencies error?

The question mark is the literal string Nest inserts where it would normally print a class name. Nest’s DI container asked the reflect-metadata registry for the constructor parameter types and got undefined back for index 0, so it had nothing else to print. Index 0 refers to the first constructor argument — whatever you wrote immediately after the opening parenthesis of constructor(.

Why does disabling emitDecoratorMetadata break NestJS dependency injection?

Nest’s DI container calls Reflect.getMetadata(“design:paramtypes”, TargetClass) at bootstrap to read constructor types as injection tokens. That metadata array is produced by the TypeScript compiler, not Nest. When emitDecoratorMetadata is false, the compiler skips the emit entirely — no fallback, no inference. Reflect.getMetadata returns undefined, Nest iterates an empty list, and every constructor parameter is left unresolved.

Does NestJS 10 support Stage 3 decorators with TypeScript 5.5?

No. Nest 10.x, the stable line as of April 2026, still ships on the legacy experimental decorators spec and has not migrated to Stage 3 decorators. Stage 3 decorators do not support the reflect-metadata bridge at all by design. On @nestjs/core 10.3 or 10.4 with TypeScript 5.5, both experimentalDecorators and emitDecoratorMetadata must stay on for implicit injection to work.

How do I fix Nest DI errors without re-enabling emitDecoratorMetadata?

Replace every implicit injection with an explicit @Inject() call, passing the provider class or token as the argument. Nest uses the token you pass as the lookup key, sidestepping the reflect-metadata path entirely. It reads the token off the custom metadata slot the decorator wrote and resolves from there. This is also how you inject non-class values like strings, symbols, or config tokens.