Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Support the official @nats-io/nats.js client instead of the deprecated nats package
Is your feature request related to a problem?
Yes. The built-in NATS transport (Transport.NATS) in @nestjs/microservices still depends on the deprecated nats npm package.
The NATS maintainers have moved the official client to the new package ecosystem under @nats-io/nats.js:
As a result, NestJS users installing the NATS transport are required to depend on a deprecated package.
Describe the solution you'd like
Migrate ServerNats (and the corresponding client implementation) to use the current official NATS client (@nats-io/nats.js, e.g. @nats-io/transport-node where applicable).
The goal would be to keep the public API stable (Transport.NATS and existing configuration options) so that most users do not need to change their application code.
Motivation / Use Case
- The current dependency (
nats) is deprecated in the NATS ecosystem.
- New NestJS projects receive deprecation warnings when using the NATS transport.
- It encourages adoption of an unmaintained package in new applications.
- The official NATS client is actively maintained by the NATS team.
- Improves long-term maintainability and aligns NestJS with the current NATS ecosystem.
Teachability, documentation, adoption, migration strategy
If any breaking changes are required, a migration guide would be helpful for existing users.
Ideally, the change could be implemented in a way that is transparent for most users.
Possible implementation
Update the internal implementation of ServerNats and related client classes to use the new NATS client while preserving the existing NestJS microservices abstraction.
Describe the solution you'd like
The NATS transport in NestJS should be updated to use the current official NATS JavaScript client ecosystem (@nats-io/nats.js), instead of relying on the deprecated nats package.
This would involve updating the internal implementation of ServerNats and the corresponding client logic to use the new maintained client.
The goal is to preserve the existing public API (Transport.NATS and current configuration options) so that this change is mostly transparent for users and does not require significant code changes in existing applications.
If a direct drop-in replacement is not possible due to API differences, an adaptation layer could be introduced to maintain compatibility.
Teachability, documentation, adoption, migration strategy
If any breaking changes are required, a migration guide should be provided to help users transition from the current nats-based implementation to the new client.
Ideally, the migration should be as transparent as possible for most users, requiring minimal or no changes in application code.
Documentation should clearly explain:
Any changes in configuration options (if applicable)
Differences between the old and new NATS client integration
Recommended upgrade path
If possible, a deprecation period for the old implementation could help reduce migration friction.
What is the motivation / use case for changing the behavior?
The current implementation requires installing the nats package, which has been deprecated by the NATS maintainers.
This leads to:
New projects receiving deprecation warnings
Usage of an unmaintained dependency
Misalignment with the current official NATS ecosystem
Migrating to the official @nats-io/nats.js client ensures:
Long-term maintenance and support
Alignment with the official NATS ecosystem
Avoidance of deprecated dependencies in new NestJS projects
Better sustainability of the microservices transport layer
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Support the official
@nats-io/nats.jsclient instead of the deprecatednatspackageIs your feature request related to a problem?
Yes. The built-in NATS transport (
Transport.NATS) in@nestjs/microservicesstill depends on the deprecatednatsnpm package.The NATS maintainers have moved the official client to the new package ecosystem under
@nats-io/nats.js:As a result, NestJS users installing the NATS transport are required to depend on a deprecated package.
Describe the solution you'd like
Migrate
ServerNats(and the corresponding client implementation) to use the current official NATS client (@nats-io/nats.js, e.g.@nats-io/transport-nodewhere applicable).The goal would be to keep the public API stable (
Transport.NATSand existing configuration options) so that most users do not need to change their application code.Motivation / Use Case
nats) is deprecated in the NATS ecosystem.Teachability, documentation, adoption, migration strategy
If any breaking changes are required, a migration guide would be helpful for existing users.
Ideally, the change could be implemented in a way that is transparent for most users.
Possible implementation
Update the internal implementation of
ServerNatsand related client classes to use the new NATS client while preserving the existing NestJS microservices abstraction.Describe the solution you'd like
The NATS transport in NestJS should be updated to use the current official NATS JavaScript client ecosystem (@nats-io/nats.js), instead of relying on the deprecated nats package.
This would involve updating the internal implementation of ServerNats and the corresponding client logic to use the new maintained client.
The goal is to preserve the existing public API (Transport.NATS and current configuration options) so that this change is mostly transparent for users and does not require significant code changes in existing applications.
If a direct drop-in replacement is not possible due to API differences, an adaptation layer could be introduced to maintain compatibility.
Teachability, documentation, adoption, migration strategy
If any breaking changes are required, a migration guide should be provided to help users transition from the current nats-based implementation to the new client.
Ideally, the migration should be as transparent as possible for most users, requiring minimal or no changes in application code.
Documentation should clearly explain:
Any changes in configuration options (if applicable)
Differences between the old and new NATS client integration
Recommended upgrade path
If possible, a deprecation period for the old implementation could help reduce migration friction.
What is the motivation / use case for changing the behavior?
The current implementation requires installing the nats package, which has been deprecated by the NATS maintainers.
This leads to:
New projects receiving deprecation warnings
Usage of an unmaintained dependency
Misalignment with the current official NATS ecosystem
Migrating to the official @nats-io/nats.js client ensures:
Long-term maintenance and support
Alignment with the official NATS ecosystem
Avoidance of deprecated dependencies in new NestJS projects
Better sustainability of the microservices transport layer