What are the risks of overusing @Global() modules in NestJS?

Difficulty: 6/10

module scope, dependency injection, application architecture

Overusing @Global() causes hidden coupling, harder testing, potential naming collisions, and refactoring friction. Consumers silently depend on global providers without declaring it, making it impossible to read a module's dependencies from its imports array alone.

Risks of overusing @Global():

1
Hidden coupling — consumers silently depend on global providers without declaring it in their imports.
2
Harder testing — unit tests must provide global providers even when the class under test doesn't obviously need them.
3
Naming collisions — two global modules exporting a provider under the same token silently shadow each other.
4
Refactoring friction — moving a global module to a different registration point causes hard-to-debug resolution errors.
5
Reduced modularity — feature modules can no longer be ported to other apps without also porting all global modules.

Preferred alternative for infrastructure providers

0-2 years experience

Difficulty: 6/10

module scope, dependency injection, application architecture

Risks of overusing @Global():

1
Hidden coupling — consumers silently depend on global providers without declaring it in their imports.
2
Harder testing — unit tests must provide global providers even when the class under test doesn't obviously need them.
3
Naming collisions — two global modules exporting a provider under the same token silently shadow each other.
4
Refactoring friction — moving a global module to a different registration point causes hard-to-debug resolution errors.
5
Reduced modularity — feature modules can no longer be ported to other apps without also porting all global modules.

Preferred alternative for infrastructure providers

0-2 years experience