Global modules in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a module is marked as global in NestJS?

Consider a NestJS module decorated with @Global(). What is the effect of this decorator on the module's providers?

NestJS

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

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

A The providers are automatically available in all modules without needing to import this module.

B The providers are available only within this module and must be imported explicitly elsewhere.

C The providers are available globally but only if the module is imported in the root module.

D The providers are available globally but only if the module is imported in every module explicitly.

💡 Hint

Think about how @Global() affects module imports and provider availability.

When a module is decorated with @Global(), its exported providers become available automatically in every module without needing to import the global module explicitly.

📝 Syntax

intermediate

Identify the correct syntax to create a global module in NestJS

Which of the following code snippets correctly defines a global module in NestJS?

A

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

@Global()
@Module({
  providers: [Service],
  exports: [Service],
})
export class GlobalModule {}

B

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

@Global
@Module({
  providers: [Service],
  exports: [Service],
})
export class GlobalModule {}

C

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

@Module({
  providers: [Service],
  exports: [Service],
})
export class GlobalModule {}

D

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

@Module({
  providers: [Service],
  exports: [Service],
})
@Global()
export class GlobalModule {}

💡 Hint

Remember the order and syntax of decorators in TypeScript.

The @Global() decorator must be placed above the @Module() decorator to correctly mark the module as global.

❓ state_output

advanced

What is the output when accessing a global provider without importing its module?

Given a global module exporting a service, what happens when another module injects that service without importing the global module?

NestJS

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

@Injectable()
export class GlobalService {
  getMessage() {
    return 'Hello from global service';
  }
}

@Global()
@Module({
  providers: [GlobalService],
  exports: [GlobalService],
})
export class GlobalModule {}

@Module({})
export class FeatureModule {
  constructor(private readonly globalService: GlobalService) {}
  printMessage() {
    return this.globalService.getMessage();
  }
}

A A runtime error occurs: Nest can't resolve dependencies of FeatureModule.

B 'Hello from global service' is returned successfully.

C The service is undefined and causes a TypeError when calling getMessage.

D The service returns null because it was not imported explicitly.

💡 Hint

Think about how global modules affect provider injection.

Global modules make their exported providers available everywhere, so FeatureModule can inject GlobalService without importing GlobalModule.

🔧 Debug

advanced

Why does a global provider cause a duplicate provider error?

Consider two global modules both exporting a provider with the same token. What error occurs and why?

NestJS

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

@Injectable()
export class SharedService {}

@Global()
@Module({
  providers: [SharedService],
  exports: [SharedService],
})
export class GlobalModuleA {}

@Global()
@Module({
  providers: [SharedService],
  exports: [SharedService],
})
export class GlobalModuleB {}

A No error occurs; NestJS merges providers automatically.

B A compile-time error occurs: Cannot redeclare class SharedService.

C The last imported global module overrides the provider silently.

D A runtime error occurs: Duplicate provider token detected.

💡 Hint

Think about how NestJS handles provider tokens in the global scope.

Having two global modules exporting providers with the same token causes a runtime error because NestJS cannot resolve which provider to use.

🧠 Conceptual

expert

How to properly share a global service with dynamic configuration?

You want to create a global module that provides a service configurable with options passed during module import. Which approach correctly supports this pattern?

A Mark the service as <code>@Injectable({ global: true })</code> and pass options via dependency injection.

B Create a global module without <code>forRoot()</code> and set configuration inside the service constructor using environment variables.

C Use <code>@Global()</code> on a module with a static <code>forRoot()</code> method returning a dynamic module with providers configured by options.

D Use <code>@Global()</code> on a module and pass options directly to the constructor of the service.

💡 Hint

Think about how NestJS supports dynamic modules and global scope.

The recommended pattern is to create a global module with a static forRoot() method that returns a dynamic module configured with providers using the passed options.

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