Proposal for @nestjs/auto-message-pattern Decorator, that I have created

[abdulrehmanwaseem]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

Hello Kamil/NestJS Team,

I hope you’re doing well! I’ve been experimenting with a small utility for NestJS microservices that removes the need to manually define message patterns. Instead of writing:

@MessagePattern('users.findAll')
findAll() {
  // ...
}

@MessagePattern('users.findOne')
findOne() {
  // ...
}

We can do:

@AutoMessagePattern()
findAll() {
  // ...
}

@AutoMessagePattern()
findOne() {
  // ...
}

The decorator automatically constructs the pattern (users.findAll, users.findOne) from the controller path or class name plus the method name. I’d love to release this as a community package under the @nestjs scope (e.g., @nestjs/auto-message-pattern) if you think it could benefit others.

Thank you for your time and for all your work on NestJS!

Best regards,
Abdul Rehman

Describe the solution you'd like

Solution Description:

I propose releasing a package (e.g., @nestjs/auto-message-pattern) that provides an @AutoMessagePattern() decorator. This decorator automatically constructs the message pattern for microservice controllers by using the controller’s metadata (from the @Controller() decorator or class name) and the method name. For example, in a controller decorated as @Controller('users'), the methods findAll() and findOne() will automatically generate the patterns users.findAll and users.findOne respectively.

Considered Drawbacks:

• Edge Cases: Custom naming conventions or advanced use cases might require manual overrides.
• Flexibility: Developers might want to customize the generated pattern further, which could necessitate additional configuration options.
• Backward Compatibility: Ensuring compatibility with existing NestJS practices and avoiding unexpected behavior in legacy projects will be important.

Overall, the solution aims to reduce boilerplate, minimize manual errors, and improve consistency in defining message patterns across microservices.

Teachability, documentation, adoption, migration strategy

can't write more

What is the motivation / use case for changing the behavior?

can't write more