ConfigurableModuleBuilder "alwaysTransient: false" (@default) doesn't work

[StiliyanKushev]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

The console log is printed only once, unless alwaysTransient is set to true.

// my-custom-module.ts

import { Inject, Module } from '@nestjs/common';

import { ConfigurableModuleBuilder } from '@nestjs/common';

export const {
  ConfigurableModuleClass,
  MODULE_OPTIONS_TOKEN: MY_CUSTOM_MODULE_OPTIONS,
} = new ConfigurableModuleBuilder<{
  baseUrl?: string;
}>().build();

@Module({})
export class MyCustomModule extends ConfigurableModuleClass {
  constructor(
    @Inject(MY_CUSTOM_MODULE_OPTIONS)
    private readonly options,
  ) {
    console.log(options);
    super();
  }
}

// app.module.ts
@Module({
  imports: [
    MyCustomModule.register({ baseUrl: 'https://google.com' }),
    MyCustomModule.register({ baseUrl: 'https://google1.com' }),
    MyCustomModule.register({ baseUrl: 'https://google2.com' }),
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Steps to reproduce

No response

Expected behavior

Expecting the console log to run 3 times because the options are different in the providers array (as stated in the official nestjs advanced concepts course).

Package

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

Other package

No response

NestJS version

10.3.0

Packages versions

[System Information]
OS Version     : Linux 6.1.69-1-MANJARO
NodeJS Version : v20.8.0
NPM Version    : 10.1.0 

[Nest CLI]
Nest CLI Version : 10.3.0 

[Nest Platform Information]
platform-express version : 10.3.0
mapped-types version     : 2.0.4
schematics version       : 10.1.0
testing version          : 10.3.0
common version           : 10.3.0
core version             : 10.3.0
cli version              : 10.3.0

[Warnings]
The following packages are not in the same minor version
This could lead to runtime errors
* Under version 10.3
- @nestjs/platform-express 10.3.0
- @nestjs/common 10.3.0
- @nestjs/core 10.3.0
* Under version 10.1
- @nestjs/schematics 10.1.0

Node.js version

v20.8.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

[micalevisk]

isn't this pretty much what the docs of alwaysTransient says here:

nest/packages/common/module-utils/configurable-module.builder.ts

Lines 35 to 42 in 3141a1e

	/**
	* Indicates whether module should always be "transient", meaning,
	* every time you call the static method to construct a dynamic module,
	* regardless of what arguments you pass in, a new "unique" module will be created.
	*
	* @default false
	*/
	alwaysTransient?: boolean;

[StiliyanKushev]

Well, here's the thing though, the expected behavior I described is not really documented, but is clearly mentioned in one of the official nestjs courses. What I'm saying is that, alwaysTransient set to true actually works as expected, but when set to false (by default), it supposedly (as shown in the course) should still act as if alwaysTransient is set to true for providers that are the same but have different options passed (such as in my example), due to their "internal hash" being different.

[StiliyanKushev]

The version used in the course seems to be v7.1.2 (edit: maybe they upgraded versions between lessons, not entirely sure)

[micalevisk]

@StiliyanKushev yeah, got you

please feel free to improve the docs at https://github.com/nestjs/docs.nestjs.com

the version shouldn't matter here

[StiliyanKushev]

Well, I'm a bit worried that this is an issue? Either a bug, or outdated course information, but the fact it worked differently before makes me believe it's the former.

Just to recap, the course suggests that the above logs should execute 3 times (due to all provders instantiating because of the different internal hashes or whatever), however (on the latest nest version at least) it only executes once unless you specifically enable alwaysTransient.

[micalevisk]

Just to recap, the course suggests that the above logs should execute 3 times

are you sure?

at 8:25

[StiliyanKushev]

That's the correct video you're referencing, but it's the wrong timestamp.
I can provide the screenshots in a sec.

[StiliyanKushev]

at 9:08

[micalevisk]

ok, I just saw what you're talking about

but please share a minimum reproduction as well

[StiliyanKushev]

Okay, I'll make a repo in a minute. I can also test with different nest versions and will report up until what version it works as expected.

[micalevisk]

check out the https://github.com/nestjs/nest/releases

I don't think that that behavior have changed but I can be wrong

[StiliyanKushev]

Yeah, already searched in the releases, wasn't mentioned. (Another reason I suspect this to be a bug).

[StiliyanKushev]

Here you go, hope that's enough :)

[StiliyanKushev]

Notice that it works as expected if I downgrade to version 9 for example.

[micalevisk]

seems to be a regression introduced on @nestjs/common@10.3.0

[StiliyanKushev]

Actually, seems to be a semi-recent bug in the latest version of @nestjs/common@10.3.0.

EDIT: yeah

[H4ad]

@micalevisk Yeah, this is a bug introduced by my PR, alwaysTransient works because of: https://github.com/nestjs/nest/pull/12753/files#diff-22f1ab07f43abbd45f270de55b6cd35da90c02fe92cee99f67d51a37b85002c8R209-R220 which makes the module unique.

That piece of code worked before because we used those objects to differentiate each module, if he use the async version, then it will have the same issue.

We can basically revert the change for that module only, the easiest/quickest fix, the other changes we don't need to revert.

We can also go back to the conversation started at #12898, this issue could be fixed using that feature.

[StiliyanKushev]

Great! Additionally I'd say this can be better documented for future reference as to me it seems to be a somewhat crucial feature in certain scenarios.

[kamilmysliwiec]

We can basically revert the change for that module only, the easiest/quickest fix, the other changes we don't need to revert.

Would you like to create a PR for this?

[kamilmysliwiec]

#13083