Global modules in NestJS - Step-by-Step Execution

Concept Flow - Global modules

Create Module

↓

Add @Global Decorator

↓

Import Module in Root Module

↓

Module Becomes Global

↓

Services Available Everywhere

↓

No Need to Import Again

This flow shows how a module becomes global in NestJS by adding @Global and importing it once, making its services available everywhere without re-importing.

Execution Sample

NestJS

import { Module, Global } from '@nestjs/common';

@Global()
@Module({
  providers: [ConfigService],
  exports: [ConfigService],
})
export class ConfigModule {}

Defines a global ConfigModule that provides ConfigService to the whole app without needing to import it multiple times.

Execution Table

Step	Action	Effect	Module State	Service Availability
1	Define ConfigModule with @Global	Marks module as global	ConfigModule(global=true)	ConfigService not yet available
2	Import ConfigModule in AppModule	Registers module globally	ConfigModule(global=true, imported in AppModule)	ConfigService available globally
3	Use ConfigService in Any Module	No need to import ConfigModule again	All modules can access ConfigService	ConfigService injected successfully
4	Try to import ConfigModule again in another module	Ignored due to global status	No duplicate imports	ConfigService still available
5	Application runs	Global services accessible everywhere	Stable global module state	ConfigService usable in all modules

💡 Global module imported once, services available app-wide without repeated imports

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
ConfigModule.global	false	true	true	true	true
ConfigService.available	false	false	true	true	true
AppModule.imports	[]	[]	[ConfigModule]	[ConfigModule]	[ConfigModule]

Key Moments - 2 Insights

Why don't we need to import a global module in every module that uses its services?

Because the @Global decorator marks the module as global, once imported in the root module, its exported providers are available everywhere automatically, as shown in execution_table step 3.

What happens if we try to import a global module multiple times?

NestJS ignores repeated imports of a global module to avoid duplication, so the module stays imported once, as shown in execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution table, at which step does ConfigService become available globally?

A Step 4

B Step 1

C Step 2

D Step 5

💡 Hint

Check the 'Service Availability' column in execution_table row for Step 2

According to variable_tracker, what is the value of ConfigModule.global after Step 1?

A false

B true

C undefined

D null

💡 Hint

Look at the 'ConfigModule.global' row and 'After Step 1' column in variable_tracker

If we remove the @Global decorator, how would the execution_table change?

A ConfigService would not be available globally after Step 2

B ConfigModule would still be global

C ConfigService would be available everywhere without import

D No change in service availability

💡 Hint

Refer to the concept_flow and execution_table steps about @Global effect

Concept Snapshot

Global modules in NestJS:
- Use @Global() decorator on a module
- Import it once in root module
- Its exported providers become available app-wide
- No need to import again in other modules
- Helps share common services easily

Full Transcript

In NestJS, a global module is created by adding the @Global decorator to a module class. This marks the module as global, so when it is imported once in the root module, its exported services become available throughout the entire application. This means other modules can use those services without importing the global module again. The execution table shows the steps: defining the module with @Global, importing it in the root module, and then using its services anywhere. Trying to import the global module multiple times does not cause duplication because NestJS ignores repeated imports of global modules. The variable tracker shows how the global flag and service availability change step by step. This approach simplifies sharing common services like configuration or logging across many modules without repetitive imports.