-
-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Description
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.