Modules and Dependency Injection

You already have a controller and a service. But how does NestJS know that controller exists? And where does it get the service it injects into its constructor? Classes sitting in files mean nothing on their own - somebody has to declare them.

The Empire did not govern its provinces from a single desk. Each had its own administration: its register of offices, its specialists, and a list of what it made available to its neighbours. The emperor knew only the list of provinces, not every clerk. In NestJS such a province is a module.

The @Module decorator

A module is a class with a decorator listing its contents:

1import { Module } from '@nestjs/common';
2
3@Module({
4  imports: [DatabaseModule],
5  controllers: [LegionController],
6  providers: [LegionService],
7  exports: [LegionService],
8})
9export class LegionModule {}

The decorator's import has a fixed shape -

import

{ Module }

from

'@nestjs/common'

Four fields describe the whole province, and each answers a different question:

controllers

providers

imports

exports

Those are all the fields of the

@Module

routes

exports - what is visible across the border

The

exports

exports

Which implies the reverse - a service registered in

providers

exports

Note what

exports

The default of being closed is deliberate. A module is meant to say explicitly what it shares - which keeps the boundaries visible and stops accidental dependencies forming between distant parts of the application.

The four steps of injection

Since a module registers providers, we can now assemble the whole dependency path. It has four steps, always in this order:

1. Define a provider with

   @Injectable()

   - a class ready to be injected.
2. Register it in the module's

   providers

   array - NestJS learns such a class exists.
3. Inject it through the constructor wherever it is needed.
4. Use the service in the class's methods.

Step two is the one easily forgotten when adding a new service: the

@Injectable()

A global module

Some things are useful everywhere - configuration, a logger, a database connection. Importing their module into every other module is then just repetition:

1@Global()
2@Module({
3  providers: [ConfigService],
4  exports: [ConfigService],
5})
6export class ConfigModule {}

The

@Global()

@Shared()

@Public()

@Universal()

One thing does not change despite the global status:

exports

@Global()

exports

Use it sparingly, @name. A global module disappears from import lists, so it stops being visible who depends on what - and that is the information that saves you on a larger project. Configuration and a logger, yes; anything else, probably not.

A provider under a name

So far we recognised providers by their class type. But you can also inject a plain value - an object, an array, a number - and those have no type:

1@Module({
2  providers: [
3    {
4      provide: 'CONFIG_TOKEN',
5      useValue: { apiUrl: 'https://api.imperium.rome', timeout: 5000 },
6    },
7  ],
8})
9export class AppModule {}

useValue

provide

Since there is no type here for NestJS to match a provider by, we name the token explicitly when injecting:

1@Injectable()
2export class ApiService {
3  constructor(@Inject('CONFIG_TOKEN') private config: { apiUrl: string }) {}
4}

@Inject('CONFIG_TOKEN')

Summary

The provinces have their administrations, the emperor knows only their list:

• a module groups related elements and declares them to NestJS - classes in files mean nothing on their own,
• the decorator's import:

  import

  ,

  { Module }

  ,

  from

  ,

  '@nestjs/common'

  ,
• the four

  @Module

  fields:

  controllers

  ,

  providers

  ,

  imports

  ,

  exports

  - there is no

  routes

  field, routes follow from controller decorators,
• a service in

  exports

  is available to importing modules; without it, it works internally only,

• exports

  removes nothing and changes nothing - it is purely a visibility declaration,
• the four injection steps:

  @Injectable()

  → register in

  providers

  → inject through the constructor → use in methods,

• @Injectable()

  alone is not enough - NestJS builds its dependency map from modules, not from scanning files,

• @Global()

  makes a module available without importing;

  @Shared()

  ,

  @Public()

  and

  @Universal()

  do not exist,
• being global does not exempt you from

  exports

  - and use it sparingly, because it hides dependencies,

• useValue

  registers a ready value,

  provide

  gives it a token, and

  @Inject('TOKEN')

  names that token when injecting.

In the next lesson you will meet controllers from the inside - you will see how a request reaches the right method. For now remember: a module is a province's administration - it registers who works here, and says explicitly what it lends to its neighbours.