NestJS Tutorial: Resolving Dependency Injection - The Order Matters

In this NestJS tutorial, we dive into our favorite framework for building server-side TypeScript. It takes much of its inspiration from Angular. One of the most loved (and occasionally hated) features of Angular is its Dependency Injection (DI) framework. The NestJS team has done a great job of introducing this DI framework to the server-side. Being server-side, there are some notable differences, but all things considered, it's a refreshing change. I encountered a familiar issue while building a new module, but I was somewhat perplexed by the solution. First, I like to use index.ts files to simplify imports when multiple classes from the same folder need to be imported. Simple.

// index.ts

export * from './auth.controller';
export * from './auth.service';
export * from './constants';
export * from './jwt.strategy'
export * from './jwt-auth.guard';
export * from './local.strategy';
export * from './local-auth.guard';

For purposes of this NestJS tutorial, I had completed authoring my module and was about to start testing/debugging when I encountered a familiar error. The DI framework was unable to resolve the dependencies (AuthService) in the AuthController.

// auth.contoller.ts

import { Controller, UseGuards, Req, Body } from '@nestjs/common';
import { AuthService, LocalAuthGuard, JwtAuthGuard } from '.';
import { Request } from 'express';
import { AuthGuard } from '@nestjs/passport';

@Controller('auth')
export class AuthController {

    constructor(
    private readonly authService: AuthService
    ) {}
    ...
}

Error

Nest can't resolve dependencies of the AuthController (?). Please make sure that the argument dependency at index [0] is available in the AuthModule context.

Potential solutions:
- If dependency is a provider, is it part of the current AuthModule?
- If dependency is exported from a separate @Module, is that module imported within AuthModule?
  @Module({
    imports: [ /* the Module containing dependency */ ]
  })

Normally, this would be resolved by simply importing the module that contained AuthService and ensuring AuthService is a provider and exported in the module. However, in this particular case AuthService was part of the AuthModule and had already been added to the providers and exports.

// auth.module.ts

import { Module } from '@nestjs/common';
import { UserModule } from '../user/user.module';
import { PassportModule } from '@nestjs/passport';
import { JwtModule } from '@nestjs/jwt';
import { jwtConstants, LocalStrategy, JwtStrategy, AuthController, AuthService } from '.';
import { LoggerModule } from '~/shared/services/log';

@Module({
    imports: [
        LoggerModule.forRoot(),
        UserModule,
        PassportModule.register({ defaultStrategy: 'local' }),
        JwtModule.register({
            secret: jwtConstants.secret,
            signOptions: { expiresIn: '60s' },
        }),
    ],
    providers: [
        AuthService,
        LocalStrategy,
        JwtStrategy,
    ],
    exports: [
        AuthService,
        PassportModule,
    ],
    controllers: [AuthController],
})
export class AuthModule {}

The solution turned out to be something I had encountered before but had long forgotten. Sometimes in DI, order seems to matter. It's not always in the place you might expect. Ultimately, the solution was to re-order the index.ts file to move the controller to the bottom of the list.

// index.ts

export * from './constants';
export * from './jwt.strategy'
export * from './jwt-auth.guard';
export * from './local.strategy';
export * from './local-auth.guard';
export * from './auth.service';
export * from './auth.controller'; // this went from the top to the botttom

In conclusion, files that don't depend on other files within the same module are placed at the top, and then are ordered according to the dependencies that occur. This means it is probably easiest to build from the bottom up. Since the module will most likely import everything else, it goes at the bottom. If there is a controller, it's probably next since it will likely import services, next would generally be services, things the services depend on, and so on. My understanding from previous NestJS tutorials is that when you import from a index.ts file, it's not just an index (also known as a pointer), but it imports the contents of the file being referenced, much like an include; therefore, the code within the files is evaluated in that order. After making this change to the order, the application started right up. If you like our content and want more NestJS tutorials, let us know by reaching us on Twitter or via email with any questions.