How does NestJS resolve a provider when the same token is exported by two different imported modules?

Q: How does NestJS resolve a provider when the same token is exported by two different imported modules?

// Both ModuleA and ModuleB export a provider under 'LOGGER' @Module({ imports: [ ModuleA, // registers LOGGER first ModuleB, // registers LOGGER second — this one wins ], }) export class AppModule {} // Any class injecting 'LOGGER' receives ModuleB's implementation // FIX — use unique namespaced tokens to prevent collisions export const MODULE_A_LOGGER = new InjectionToken('ModuleA.Logger'); export const MODULE_B_LOGGER = new InjectionToken('ModuleB.Logger'); Use Symbol() or InjectionToken for all non-class provider tokens — they are inherently unique. Namespace string tokens with the module name: 'AuthModule.JwtSecret' not just 'JwtSecret'. Avoid having two modules export providers under the same token. Document which module is the authoritative source for shared infrastructure tokens. Token shadowing is silent — there are no warnings at startup, only wrong behavior at runtime.

Difficulty: 6/10

module imports, provider token conflict, dependency injection

The last provider registered for a given token wins. NestJS uses the order of the imports array to determine precedence — the module listed later takes priority. This silent shadowing is a common source of bugs and is best prevented by using unique namespaced tokens such as Symbols or InjectionToken.

Token collision — last import wins

How to prevent token collision:

1
Use Symbol() or InjectionToken for all non-class provider tokens — they are inherently unique.
2
Namespace string tokens with the module name: 'AuthModule.JwtSecret' not just 'JwtSecret'.
3

How does NestJS resolve a provider when the same token is exported by two different imported modules?

Scenario Questions

Follow-up Questions