@Global() registers the module's exported providers into the global DI scope. Any module in the application can inject those providers without listing the module in its own imports array. The global module must still be imported once — typically in AppModule — to be registered.

Global module registration and usage

Important rules for @Global():

1
The module must still be imported once — usually in AppModule — to be registered in the container.
2
After registration, its exports are available to every module without explicit imports.
3
Only providers listed in exports are available globally — providers not exported remain private.
4
Use @Global() sparingly — it hides dependencies and makes modules harder to test in isolation.

Difficulty: 5/10

Topics: global providers, module scope, dependency injection

Scenario Questions

0-2 years experience

1
You need a ConfigService available in many feature modules without importing ConfigModule everywhere. How would you set it up using @Global()?
2
If you add @Global() to a module but forget to export a provider, what will happen when another module tries to inject it?

2-5 years experience

1
During a sprint you refactor a shared LoggerModule to be global. After the change, a feature module that previously imported LoggerModule starts throwing a circular dependency error. Why might that happen?
2
You notice that a unit test for a controller fails because a globally provided AuthService is not mocked. How would you adjust the test setup to handle the global provider?

5-8 years experience

1
Your team is scaling a microservice architecture and wants to avoid importing common utility modules in each NestJS microservice. Discuss the trade‑offs of making those modules global versus using a shared library.
2
A performance audit shows that a globally scoped provider is instantiated multiple times unexpectedly. Explain how NestJS handles provider scope with @Global() and how you would fix the issue.

8+ years experience

1
Looking ahead, you need to migrate several legacy NestJS applications into a monorepo. Some of them rely on global modules. How would you design a strategy to manage global providers to keep the monorepo maintainable and avoid hidden coupling?
2
Your organization wants to enforce a policy that only certain core services can be global. Propose an architectural guideline and tooling approach to audit and enforce correct usage of @Global() across many teams.

Follow-up Questions

❓What are the main downsides of making a module global?
❓Can you override a global provider in a specific module, and how?
❓How does @Global() affect unit testing of individual modules?