Suggest an edit

Improve this article

Refine the answer for “What are global providers?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## What a global provider is

A **global provider** is a provider that's
**available throughout the whole NestJS application**,
even if the module where it's declared **isn't explicitly imported** into other modules.

> In other words: once you register a provider as global,
> you no longer need to list `imports: [SomeModule]` in every module,
> NestJS makes that provider available everywhere on its own.

## An example without a global provider

```javascript
// logger.service.ts
@Injectable()
export class LoggerService {
  log(msg: string) {
    console.log(`[LOG]: ${msg}`);
  }
}

// logger.module.ts
@Module({
  providers: [LoggerService],
  exports: [LoggerService],
})
export class LoggerModule {}
```

To use `LoggerService` in other modules,
you have to **import** `LoggerModule` **manually** everywhere it's needed:

```javascript
@Module({
  imports: [LoggerModule],
})
export class UsersModule {}
```

## An example with a global provider

Let's make the module **global**, using the `@Global()` decorator:

```javascript
import { Global, Module } from '@nestjs/common';
import { LoggerService } from './logger.service';

@Global()
@Module({
  providers: [LoggerService],
  exports: [LoggerService],
})
export class LoggerModule {}
```

Now `LoggerService` is available **in every module** of the application,
even if `LoggerModule` **is never imported anywhere**.

```javascript
@Injectable()
export class UsersService {
  constructor(private readonly logger: LoggerService) {}

findAll() {
    this.logger.log('Fetching users...');
    return ['John', 'Alex'];
  }
}
```

NestJS automatically registers `LoggerService` in the **global DI container**,
so it's available anywhere with no extra imports.

## How this works internally

- Every module in NestJS has its **own scope**.
- When you add `@Global()`, Nest **registers the module's providers in the root container**.
- Every other module "sees" those providers, even without importing the module.

## Where this is useful

Global providers are typically used for **application-wide services**, for example:

| Service type | Example |
|---|---|
| Authorization | `AuthService`, `JwtService`, `AuthGuard` |
| Configuration | `ConfigService` from `@nestjs/config` |
| Logging | `LoggerService` |
| Caching | `CacheService`, `RedisService` |
| Events / notifications | `EventBus`, `NotificationService` |

## Important: be careful with globality

While convenient, **global providers shouldn't be overused**.

### The downsides:

- it's hard to trace where a dependency comes from;
- it breaks **module encapsulation**;
- **naming conflicts** are possible with a lot of global providers;
- testing gets harder (mocks have to be substituted globally).

Better:

- use global providers **only for infrastructure** (logger, config, cache);
- keep business logic modular.

## An alternative: global registration without `@Global()`

Sometimes you can register a **global provider programmatically**,
e.g. in `main.ts` or via a **Dynamic Module**.

### An example via `app.useGlobalFilters()`, `app.useGlobalPipes()`, `app.useGlobalInterceptors()`

```javascript
const app = await NestFactory.create(AppModule);
app.useGlobalFilters(new HttpExceptionFilter());
app.useGlobalPipes(new ValidationPipe());
app.useGlobalInterceptors(new LoggingInterceptor());
```

These elements also become **global providers**,
but at the level of **the whole application** (with no `@Global()` decorator).

## A dynamic global module example

```javascript
@Global()
@Module({})
export class ConfigModule {
  static forRoot(envFile: string): DynamicModule {
    return {
      module: ConfigModule,
      providers: [
        {
          provide: 'CONFIG_PATH',
          useValue: envFile,
        },
        ConfigService,
      ],
      exports: [ConfigService],
    };
  }
}
```

Now `ConfigService` is globally available everywhere.

## Summary

| Concept | Description |
|---|---|
| Global provider | A provider available in every module with no explicit import |
| Created via | `@Global()` on a module, or `useGlobal*()` at initialization |
| Used for | System-wide services: logger, config, authentication |
| Advantages | Simplifies the architecture, fewer imports |
| Disadvantages | Hidden dependencies, harder to test, risk of conflicts |
| Recommendation | Make only infrastructure services global, and keep business logic modular |

Markdown · drag & drop images · ⌘B / ⌘I shortcuts571 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.