Correct way to initialize ClsModule when multiple third party modules use CLS

[nishkarsh-beamery]

I am working on a NestJS application that uses multiple custom node modules that use CLS. For example, a library for managing auth and another for traceability.

Both of the libraries export NestJS modules that import and use ClsModule. What is the correct way to initialize ClsModule in this scenario? Should the individual libraries use ClsModule.forRoot() or does the host application need to do that in app.module.ts? Both the libraries need to mount the middleware to all the routes.

What would be the effect when ClsModule.forRoot() is called multiple times, would it get access to the same storage or would it create multiple underlying stores?

[Papooch]

That's a tough call. The ClsModule isn't built such that multiple forRoot registrations in a single application are supported, as it depends on some global state (as is the case with most modules with the forRoot method).

I can straight up say, that if you use forRoot multiple times, then the Proxy Providers feature will break, because it uses a shared global array.

But, as long as nestjs-cls is a peer depency of those libraries (and/or they're de-duplicated in node_modules, meaning there's only a single place from where it is imported), then the underlying storage should be the same regardless of how many times you register it.

That said, I wouldn't recommend calling forRoot multiple times, the library wasn't built for it.

[nishkarsh-beamery]

Thank you for your explanation.

So in this case, would a recommended way to initialize it using forRoot() be in the host application's app.module.ts and then individual libraries just specify it as a peer-dependency and import ClsModule without forRoot()?

[Papooch]

Yes, that would be the safest option.

I should probably add some information to the docs about it.

[Papooch]

An new section for library authors has been added to the docs