What is the module encapsulation rule in NestJS and why does it matter?

Q: What is the module encapsulation rule in NestJS and why does it matter?

// AuthModule declares JwtService but does NOT export it @Module({ providers: [JwtService] }) // JwtService is private export class AuthModule {} // UsersModule imports AuthModule — but JwtService is NOT exported @Module({ imports: [AuthModule], providers: [UsersService] }) export class UsersModule {} // UsersService tries to inject JwtService — FAILS at startup // Error: Nest can't resolve dependencies of UsersService (?) // FIX: export JwtService from AuthModule @Module({ providers: [JwtService], exports: [JwtService] }) export class AuthModule {} Provides a clear public API — exports array is a module's contract with the outside world. Prevents accidental coupling — internal helpers stay private and can be changed freely. Startup-time enforcement — NestJS throws immediately if a dependency boundary is violated. Improves testability — modules can be tested in isolation by mocking only their declared exports.

Difficulty: 5/10

module imports, provider scope, circular dependencies

A provider is only injectable within the module that declares it unless it is explicitly listed in that module's exports. Trying to inject an unexported provider from another module throws a dependency resolution error at startup. This rule keeps modules honest — you can read a module's public API just by looking at its exports array.

Encapsulation violation and fix

Why encapsulation matters:

1
Provides a clear public API — exports array is a module's contract with the outside world.
2
Prevents accidental coupling — internal helpers stay private and can be changed freely.
3
Startup-time enforcement — NestJS throws immediately if a dependency boundary is violated.
4
Improves testability — modules can be tested in isolation by mocking only their declared exports.

Scenario Questions

0-2 years experience

Follow-up Questions