#Missing Dependency in shared module

5 messages · Page 1 of 1 (latest)

languid light
#

We were building a pnpm-workspace monorepo with a nest app and some side libraries. Now we start building a second app and we want to extract some shared domain modules to a library(Some wrapper modules of logic connect to another internal service).

These shared domain modules have some DI services originally provided by global module in the app, however, after I moved a module to this shared package and import from it. As long as I start the dev server and the app says the injected service is missing and I got error like

Nest can't resolve dependencies of the <XService> (?, HttpService). Please make sure that the argument Logger at index [0] is available in the <XModule> context.

Any idea how can I fix that? The Logger for example, is exported from LoggerMoudle which is set as global module in the app.module.ts

glossy haven
#

Can you show roughly the monorepo structure? What are apps, what are libraries? Which app is dependent on which libraries? From your explanation, I can't put a mental picture together and that is necessary to be able to give you a proper answer.

languid light
# glossy haven Can you show roughly the monorepo structure? What are apps, what are libraries? ...

Sure. Structure is similar to nestjs's monorepo structure

apps
  |- app1
  |- app2  
libs
  |- sdk1
  |- new-shared-module

Both app1 &app2 uses the sdk1 for dto and response types etc but sdk1 is not relying on nestjs modules at all. I'm building a new library new-shared-module aiming to have shared modules between app1 & app2, they have some global module enabled in their root app.module.ts with services like custom logging & custom httpService. (These two apps also use a published custom LoggerModule & HttpModule with no problem)

However, when I moved one shared module to new-shared-module , this module won't be able find the global logging & httpService module in its context.

languid light
#

The reason might be that our new-shared-module is having @nestjs/common of version ^10.3.7 while the app1 is having @nestjs/common as ^10.2.4 which makes pnpm install having 2 different logger installed and thus the one injected in app1 cannot be found when runing in the service of new-shared-module.

Have you ever faced this situation and is there a solution to it?

glossy haven
#

Well, I use Rush as a monorepo manager with PNPM as the package manager and Rush's recommended config is to enforce strict peer dependencies so installing will fail, if peer deps aren't met and to ensure consistent versions to be certain the same version across all apps and libraries are installed. You are probably running into the NPM doppelganger issue. Rush also has a tool to investigate your lock file, which indicates when you have doppelgangers. They say PNPM solves the doppelganger problem, but it still happens.

And yes, I faced this situation before. 🙂 It was also two different versions of Nest common. I fixed it, I believe, by just making sure versions matched (by setting the suggested config value in Rush, which then said, "oops, you have two different versions of Nest/common, so I had to fix it 🙂 ).