Skip to content

Inconsistent use of 'RMQ_' and 'RQM_' prefixes in RabbitMQ-related constants #15786

@CodeVac513

Description

@CodeVac513

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

While reviewing the microservices code related to RabbitMQ, I noticed that some constants use the prefix RQM_, while others use RMQ_.

For example:

export const RQM_DEFAULT_QUEUE_OPTIONS = {};
export const RQM_DEFAULT_NOACK = true;
export const RQM_DEFAULT_PERSISTENT = false;
export const RQM_DEFAULT_NO_ASSERT = false;
export const RMQ_SEPARATOR = '.';
export const RMQ_WILDCARD_SINGLE = '*';
export const RMQ_WILDCARD_ALL = '#';

I tried to find documentation or other references for the RQM_ prefix but couldn’t locate anything relevant.
My assumption is that RQM_ might be a typo for RMQ_, which is the more commonly used abbreviation for RabbitMQ.

If this is indeed an inconsistency, I’d be happy to open a PR to help align the naming.
However, if the use of RQM_ is intentional, could you kindly clarify its meaning or purpose?

Please feel free to let me know if this isn’t the appropriate place to bring this up — I’m happy to adjust or close the issue if needed.

Thanks in advance, and thank you for all the great work on NestJS!

Describe the solution you'd like

It might be clearer to use a consistent prefix (preferably RMQ_) for RabbitMQ-related constants across the codebase, unless RQM_ has a specific intended meaning.

Teachability, documentation, adoption, migration strategy

This is a small internal naming improvement, so no migration is needed.
If the prefix is updated for consistency, it would only affect a few internal constants.
No changes to documentation or public APIs would be required.

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

Having two different prefixes (RMQ_ and RQM_) for RabbitMQ-related constants can be confusing for contributors and users reading the code.
Consistent naming improves readability, helps prevent misunderstanding, and makes the codebase easier to maintain.
Clarifying whether the two prefixes are intentional or not also helps avoid accidental misuse in future contributions.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions