Topic

Modules

Definition

A Nest module is a class annotated with @Module that declares the controllers and providers belonging to a cohesive part of the application, and the imports/exports that make dependencies available across module boundaries.

In simpler words

A module is a labeled box: it says which controllers and services live here, what it needs from elsewhere, and what it is willing to share.

Every Nest feature — tickets, auth, health — is a module. AppModule is the root module that assembles the whole app. Understand modules before controllers; they tell you what exists.

Open official example (opens in new tab)

After this you can

Explain the four @Module keys: imports, controllers, providers, exports
Explain TypeOrmModule.forFeature([Ticket]) inside TicketsModule
Trace how AppModule assembles Health/Users/Auth/Tickets modules
Know when a provider must be exported

@Module anatomy

Definition

The @Module decorator accepts a metadata object with optional imports, controllers, providers, and exports arrays that Nest reads to build the application’s dependency graph.

In simpler words

imports = other modules this one needs; controllers = routes it exposes; providers = services it owns; exports = which of its providers others may use.

Nest reads @Module metadata at bootstrap to construct a dependency-injection graph — it does not scan folders or filenames, only decorator metadata.

A provider not listed in providers cannot be injected here, even if the class exists in the same folder. A provider not listed in exports cannot be injected by a different module that imports this one.

TicketsModule

@Module({
  imports: [TypeOrmModule.forFeature([Ticket])],
  controllers: [TicketsController],
  providers: [TicketsService],
})
export class TicketsModule {}

forFeature([Ticket]) registers a TypeORM Repository<Ticket> that TicketsService can inject.

The root module wires the whole app

Definition

A root module is the single module passed to NestFactory.create that transitively imports every feature module the application needs.

In simpler words

AppModule is the top of the tree — if a module is not (directly or indirectly) imported by AppModule, Nest never loads it.

A root app.module.ts imports things like ConfigModule, TypeOrmModule.forRoot(...), HealthModule, UsersModule, AuthModule, and TicketsModule — that list is the entire backend surface.

AppModule also implements NestModule to register CorrelationIdMiddleware across every route via configure(consumer) — middleware registration is a module-level concern, separate from providers/controllers.

AppModule imports

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    TypeOrmModule.forRoot({ type: 'postgres', url: env.DATABASE_URL, synchronize: false /* ... */ }),
    HealthModule,
    UsersModule,
    AuthModule,
    TicketsModule,
  ],
})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(CorrelationIdMiddleware).forRoutes('*');
  }
}

Add a new feature module here and its controllers become reachable; forget this step and its routes 404.

Exporting providers across module boundaries

Definition

A module makes a provider available to importing modules by listing that provider in its exports array; the importing module must also import the exporting module.

In simpler words

To borrow a service from another module, that module must export it and your module must import it — both sides are required.

If AuthModule needs UsersService to look up credentials, UsersModule must export UsersService and AuthModule must import UsersModule.

Forgetting exports is a very common first bug: the provider exists and even compiles, but Nest throws a runtime "cannot resolve dependencies" error, because the DI container cannot see it outside its owning module.

Mistake: missing export

// Wrong — UsersService not exported
@Module({ providers: [UsersService] })
export class UsersModule {}

// Right
@Module({ providers: [UsersService], exports: [UsersService] })
export class UsersModule {}

Without exports, importing UsersModule elsewhere still cannot inject UsersService.

Keep in mind

Understand a feature by its module first: imports tell you dependencies, controllers/providers tell you what it does.
Circular module imports usually mean a boundary is drawn in the wrong place — extract a shared module.
Keep feature modules focused: tickets should not import unrelated modules “just in case”.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. What must a module list for Nest to wire it?

Concept

The controllers and providers it owns (plus imports/exports as needed)Only the providers, since controllers are discovered automaticallyThe entities and repositories it uses instead of controllersThe routes and their HTTP methods as string keys

2. When can another module inject a provider?

Syntax

As soon as the provider is marked @Injectable, regardless of exportsAfter the owning module exports that providerAfter the consuming module adds the owning module to its exports arrayOnly after the provider is registered as a global value in main.ts

3. Is @Module optional if @Injectable exists?

Practical

Yes — @Injectable registers the class in the nearest module automaticallyYes — the DI container scans every @Injectable class at startupNo — Nest still needs module metadata to register the providerNo — but only because @Module also replaces the need for @Injectable

4. What do imports on @Module mean?

Logic

Other modules whose exported providers you want to useThe individual providers from other modules you want to injectThe controllers from other modules you want to expose routes forThe npm packages the module depends on at runtime

5. What is AppModule typically?

Concept

A feature module that AppModule itself must be imported intoA global module whose providers every other module inherits by defaultThe root module that imports feature modulesThe controller that maps the application root route

6. Why export a service from AuthModule?

Practical

So TicketsModule (or others) can inject Auth-related providersSo the service becomes a singleton instead of a per-request providerSo AuthModule can inject providers from the modules that import itSo the service is registered in the DI container in the first place

7. What happens if you forget to add a provider to providers[]?

Syntax

Nest falls back to constructing it with new but without its dependenciesIt works, but a fresh instance is created on every injectionNest cannot inject it and DI fails at runtime/startupNest resolves it from any other module that exports a similar class

8. Can controllers be provided without being listed?

Logic

Yes — a controller listed in providers is also registered for routingYes — controllers imported from another module expose their routesNo — controllers must be listed in both controllers and providersNo — controllers must appear in the module controllers array

9. What is a shared module pattern?

Concept

A module that exports common providers imported by many featuresA single module that lists every controller in the applicationA module marked @Global so its providers need no exports arrayA module that other modules extend through class inheritance

10. Which claim about global modules is true?

Practical

They expose all of their providers even without an exports arrayThey reduce repeated imports but should be used sparingly for clarityThey make every provider in the app injectable everywhere at onceThey replace constructor injection with automatic property injection

11. OrdersModule injects AuthService from AuthModule but DI fails. What is missing?

Conceptadvanced

@Module({
  providers: [AuthService],
  // exports: []
})
export class AuthModule {}

AuthModule must list AuthService in its imports arrayAuthService must be decorated with an @Export() to leave the moduleAuthModule must add AuthService to exports so importing modules can inject itOrdersModule must import AuthService directly instead of AuthModule

12. To use the exported providers of AuthModule, what does OrdersModule need?

Syntaxintermediate

@Module({
  imports: [/* ? */],
  controllers: [OrdersController],
  providers: [OrdersService],
})
export class OrdersModule {}

AuthService listed in the OrdersModule providers arrayAuthModule listed in the imports arrayAuthModule listed in the OrdersModule exports arrayAuthService injected with an @Inject("AuthModule") token

13. Why must TicketsService be listed in providers here?

Practicalintermediate

@Module({
  controllers: [TicketsController],
  providers: [TicketsService],
})
export class TicketsModule {}

So its public methods are registered as HTTP routesSo the DI container can construct and inject it into the controllerSo it is exported automatically to every module that imports this oneSo Nest creates a new instance of it for each request

14. What does @Global() change for ConfigService?

Logicadvanced

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

ConfigService becomes injectable everywhere without importing ConfigModule each timeIt automatically exports every provider in ConfigModule, not just this oneIt removes the need to list ConfigService in the exports arrayIt changes ConfigService from a singleton to a per-request provider

15. TicketsController routes return 404. What is missing from the module?

Conceptintermediate

@Module({
  controllers: [/* ? */],
  providers: [TicketsService],
})
export class TicketsModule {}

It must be added to providersIt must be exportedTicketsController must be added to the controllers arrayIt must be imported as a module

Checking your session…