Service Injection Issue in Guard Across Modules

[kallekulp]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current behavior

Unable to inject a service to a guard from one module down. I don't know if this is related to how guards are constructed but I have the following scenario:

I have AppModule, AModule and BModule.

AppModule is allowed to import AModule which defines AuthGuard (example). AuthGuard is then exported from AModule. AModule is allowed to import BModule which defines a service, that needs to be injected into the AuthGuard. AppModule is not allowed to import BModule.

The following structure is based on linter rules ( "@nx/enforce-module-boundaries":)

With the current setup it throws me the following Error:

`Error: Nest can't resolve dependencies of the AuthGuard (?). Please make sure that the argument BService at index [0] is available in the AppModule context.

Potential solutions:

• Is AppModule a valid NestJS module?
• If BService is a provider, is it part of the current AppModule?
• If BService is exported from a separate @Module, is that module imported within AppModule? @Module({ imports: [ / the Module containing BService / ] }) `

If I inject the AuthGuard into the constructor of AppController it works.

Is this approach even possible?

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';

import { AModule } from "./modules/a/a.module";

@Module({
  imports: [AModule],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

import { Module } from '@nestjs/common';
import { AuthGuard } from './auth.guard'; // Import AuthGuard from the same directory
import { BModule } from "../b/b.module"; // Import SubModule from a higher level directory

@Module({
  imports: [BModule],
  providers: [AuthGuard],
  exports: [AuthGuard],
})
export class AModule {}

import { Module } from '@nestjs/common';
import { BService } from "./b.service"; // Import SubModule from a higher level directory

@Module({
  imports: [],
  providers: [BService],
  exports: [BService], // Export AuthGuard so that it can be used in other modules
})
export class BModule {}

import { Injectable, CanActivate, ExecutionContext } from "@nestjs/common";
import { Observable } from "rxjs";

import { BService } from "../b/b.service"; // Import SubService from the submodule

@Injectable()
export class AuthGuard implements CanActivate {
  constructor(private bService: BService) {
  } // Inject SubService into AuthGuard

  canActivate(
    context: ExecutionContext
  ): boolean | Promise<boolean> | Observable<boolean> {
    // Use SubService in your guard logic
    return true; // Replace with your actual guard logic
  }
}

Minimum reproduction code

https://github.com/kallekulp/nest-js-usecase

Steps to reproduce

1. nest start --watch
2. Error is thrown in the terminal

Expected behavior

I expect that the Guard constructor and dependency tree would work the same way as it works if I'd inject it the Guard/Service into the controller's constructor

Package

• [X] I don't know. Or some 3rd-party package
• [ ] code>@nestjs/common</code
• [ ] code>@nestjs/core</code
• [ ] code>@nestjs/microservices</code
• [ ] code>@nestjs/platform-express</code
• [ ] code>@nestjs/platform-fastify</code
• [ ] code>@nestjs/platform-socket.io</code
• [ ] code>@nestjs/platform-ws</code
• [ ] code>@nestjs/testing</code
• [ ] code>@nestjs/websockets</code
• [ ] Other (see below)

Other package

No response

NestJS version

10.3.8

Packages versions

{
  "name": "test-app",
  "version": "0.0.1",
  "description": "",
  "author": "",
  "private": true,
  "license": "UNLICENSED",
  "scripts": {
    "build": "nest build",
    "format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"",
    "start": "nest start",
    "start:dev": "nest start --watch",
    "start:debug": "nest start --debug --watch",
    "start:prod": "node dist/main",
    "lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage",
    "test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
    "test:e2e": "jest --config ./test/jest-e2e.json"
  },
  "dependencies": {
    "@nestjs/common": "^10.0.0",
    "@nestjs/core": "^10.0.0",
    "@nestjs/platform-express": "^10.0.0",
    "reflect-metadata": "^0.2.0",
    "rxjs": "^7.8.1"
  },
  "devDependencies": {
    "@nestjs/cli": "^10.0.0",
    "@nestjs/schematics": "^10.0.0",
    "@nestjs/testing": "^10.0.0",
    "@types/express": "^4.17.17",
    "@types/jest": "^29.5.2",
    "@types/node": "^20.3.1",
    "@types/supertest": "^6.0.0",
    "@typescript-eslint/eslint-plugin": "^6.0.0",
    "@typescript-eslint/parser": "^6.0.0",
    "eslint": "^8.42.0",
    "eslint-config-prettier": "^9.0.0",
    "eslint-plugin-prettier": "^5.0.0",
    "jest": "^29.5.0",
    "prettier": "^3.0.0",
    "source-map-support": "^0.5.21",
    "supertest": "^6.3.3",
    "ts-jest": "^29.1.0",
    "ts-loader": "^9.4.3",
    "ts-node": "^10.9.1",
    "tsconfig-paths": "^4.2.0",
    "typescript": "^5.1.3"
  },
  "jest": {
    "moduleFileExtensions": [
      "js",
      "json",
      "ts"
    ],
    "rootDir": "src",
    "testRegex": ".*\\.spec\\.ts$",
    "transform": {
      "^.+\\.(t|j)s$": "ts-jest"
    },
    "collectCoverageFrom": [
      "**/*.(t|j)s"
    ],
    "coverageDirectory": "../coverage",
    "testEnvironment": "node"
  }
}

Node.js version

18.17.0

In which operating systems have you tested?

• [ ] macOS
• [X] Windows
• [ ] Linux

Other

No response

[micalevisk]

:warning: We use GitHub Issues to track bug reports, feature requests and regressions

Try the following instead:

• use our Discord community
  
• use StackOverflow using the tag nestjs
• make this question at StackOverflow instead

[kallekulp]

I think this shouldn't be closed. It seems like it's a bug. Even with the minimal setup this doesn't work. Meaning you cannot inject a dependency two layers down into the guard

[KostyaTretyak]

@kallekulp, this is not a bug, this is a feature.