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.

Practice

1. What is the main purpose of marking a module with @Global() in NestJS?

easy

A. To disable dependency injection for the module

B. To make its providers available across the entire application without importing the module repeatedly

C. To automatically register the module as a controller

D. To restrict the module's providers to only one feature module

Solution

1. Step 1: Understand the role of @Global()

   The @Global() decorator marks a module so its providers can be used app-wide without importing it in every module.

2. Step 2: Compare options with this behavior

   Only To make its providers available across the entire application without importing the module repeatedly correctly describes this behavior; others describe unrelated or incorrect effects.

3. Final Answer:

   To make its providers available across the entire application without importing the module repeatedly -> Option B

4. Quick Check:

   Global modules share providers app-wide [OK]

Hint: Global modules share providers app-wide without imports [OK]

Common Mistakes:

• Thinking @Global restricts providers to one module
• Confusing @Global with controller registration
• Assuming @Global disables dependency injection

2. Which of the following is the correct way to declare a global module in NestJS?

easy

A. @Global() @Module({ providers: [MyService], exports: [MyService] }) export class MyModule {}

B. @Module({ global: true, providers: [MyService], exports: [MyService] }) export class MyModule {}

C. @GlobalModule() @Module({ providers: [MyService] }) export class MyModule {}

D. @Module({ providers: [MyService], global: true }) export class MyModule {}

Solution

1. Step 1: Recall the correct decorator for global modules

   In NestJS, @Global() is used above the module class to mark it global.

2. Step 2: Check syntax correctness

   @Global() @Module({ providers: [MyService], exports: [MyService] }) export class MyModule {} correctly uses @Global() and @Module() with providers and exports arrays.

3. Final Answer:

   @Global() @Module({ providers: [MyService], exports: [MyService] }) export class MyModule {} -> Option A

4. Quick Check:

   Use @Global() decorator above @Module() [OK]

Hint: Use @Global() decorator above @Module() to declare global module [OK]

Common Mistakes:

• Using 'global: true' inside @Module() which is invalid
• Using non-existent @GlobalModule() decorator
• Forgetting to export providers in global module

3. Given this global module declaration:

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

What happens if another module imports ConfigModule again?

medium

A. The application will throw a runtime error due to duplicate imports

B. The providers from ConfigModule are duplicated and cause errors

C. The providers are shared globally, so importing again has no effect

D. The ConfigModule providers become private to the importing module

Solution

1. Step 1: Understand global module behavior on imports

   Global modules share their providers app-wide, so importing them multiple times does not duplicate providers.

2. Step 2: Analyze the effect of importing a global module again

   Importing a global module again is harmless; providers remain shared and singleton.

3. Final Answer:

   The providers are shared globally, so importing again has no effect -> Option C

4. Quick Check:

   Global modules share providers; repeated imports don't duplicate [OK]

Hint: Global modules share providers; repeated imports don't duplicate [OK]

Common Mistakes:

• Assuming repeated imports cause errors
• Thinking providers become private on re-import
• Confusing global modules with normal modules

4. Consider this code snippet:

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

But when you try to inject LoggerService in another module, you get an error: Nest can't resolve dependencies. What is the likely cause?

medium

A. You forgot to import LoggerModule in the root module

B. You did not mark LoggerModule with @Global()

C. You forgot to export LoggerService from LoggerModule

D. You did not add @Injectable() to LoggerService

Solution

1. Step 1: Check the module declaration

   The module is marked global and exports LoggerService, so imports and exports are correct.

2. Step 2: Verify LoggerService setup

   If LoggerService lacks @Injectable(), NestJS cannot inject it, causing the error.

3. Final Answer:

   You did not add @Injectable() to LoggerService -> Option D

4. Quick Check:

   Missing @Injectable() on service causes injection errors [OK]

Hint: Check if service has @Injectable() decorator [OK]

Common Mistakes:

• Assuming global modules don't need imports anywhere
• Forgetting to export providers
• Confusing missing @Global() with injection errors

5. You want to create a global module that provides a configuration service with environment variables. Which of the following is the best practice to ensure the service is singleton and accessible everywhere without repeated imports?

hard

A. Mark the module with @Global(), export the service, and import it only once in the root module

B. Mark the module with @Global(), export the service, and import the module in every feature module

C. Mark the module with @Global(), export the service, and do not import it anywhere else

D. Do not mark the module global; import it in every module that needs it

Solution

1. Step 1: Understand global module usage

   Global modules provide their exported providers app-wide without needing to import them repeatedly.

2. Step 2: Determine import requirements for global modules

   Global modules must be imported once, typically in the root module; after that, providers are available app-wide without further imports.

3. Final Answer:

   Mark the module with @Global(), export the service, and import it only once in the root module -> Option A

4. Quick Check:

   Import global modules once in root module [OK]

Hint: Global modules: mark @Global(), export, import once in root [OK]

Common Mistakes:

• Importing global modules in every feature module
• Not importing global modules at all
• Not marking the module as global