#Nest can't resolve dependencies of the DiscoveryService

1 messages · Page 1 of 1 (latest)

brisk meteor
#

I've been using NestJS for some time now, but this error is new to me.

[Nest] 23628  - 22/01/2024, 09:22:18   ERROR [ExceptionHandler] Nest can't resolve dependencies of the DiscoveryService (?). Please make sure that the argument ModulesContainer at index [0] is available in the DiscoveryModule context.

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

I have a package which is used for shared NestJS utilities. The package contains a HealthModule which is used to monitor various parts of a service.

import { HealthOptionsKey, HealthService } from "./health.service";
import { DynamicModule, Module } from "@nestjs/common";
import { HealthController } from "./health.controller";
import { DiscoveryModule } from "@nestjs/core";

@Module({})
export class HealthModule {
    static forRoot(options: HealthService.Options): DynamicModule {
        return {
            global: true,
            module: HealthModule,
            imports: [DiscoveryModule],
            controllers: [HealthController],
            providers: [
                {
                    provide: HealthOptionsKey,
                    useValue: options,
                },
                HealthService,
            ],
            exports: [HealthService],
        };
    }
}

When I use this module, the error above is thrown. It's working completely fine for a rest application, but not using a grpc microservice. Here's the AppModule for the grpc microservice which uses the HealthModule

import { HealthModule } from "@gamedex/nest";
import { Module } from "@nestjs/common";
import config from "@config";

@Module({
    imports: [
        HealthModule.forRoot({
            appConfig: config.app,
            buildConfig: config.build,
        })
    ],
})
export class AppModule {}

Both versions of @nestjs/core and @nestjs/common match in the package and service.

brisk meteor
#

Fixed by installing @nestjs/core and @nestjs/common in the root of the workspace

#

makes sense ig because of DI

brisk meteor
#

is there a way to do it with peer dependencies?

sick tangle
#

I haven't used moonrepo before, so not sure what the approach usually is with that monorepo tool, but generally with monorepos I advocate for installing all @nestjs/ dependencies in the workspace root to ensure that every ModuleRef/ModuleContainer/etc that gets imported is the exact same one from the same version and same location. Otherwise, you'll run into issues where even the same version of ModuleRef will an instanceof check due to how Realms in JS works.

Packages should always set @nestjs/ deps to peerDependencies (assuming they should also be installed in the consuming application) to make sure they don't introduce this problem themselves, and when working locally, be wary of using any link from package managers, as they usually don't properly respect peerDependencies

brisk meteor
#

Thanks for the insight!

dense fractal
# sick tangle I haven't used moonrepo before, so not sure what the approach usually is with th...

I've been thinking about this problem but haven't done much beyond a POC. I was worried about resolving this dependency issue. The use side I've tried pursuing is making a nest module a private npm package that I can import in multiple projects. Based off your comment, it looks like I need to set deps to peerDependencies. Do you know a good place to read more about this issue? My Google foo on this has been subpar so far.

sick tangle
dense fractal
#

If you did I'd love to give it a read