RFC: Split up health indicators into multiple packages

The goal of this RFC is to validate the design with the community, solicit feedback on open questions, and enable experimentation via a non-production-ready prototype included in this proposal.

✏️ Motivation

@nestjs/terminus currently loads third party packages lazily. For instance, in order to use theTypeOrmHealthIndicator one must install @nestjs/typeorm and typeorm package.

Here is an example of the TypeOrmHealthIndicator implementing the package check:

https://github.com/nestjs/terminus/blob/0dfc7256dfc227ee3084108b8896d749008f78e9/lib/health-indicator/database/typeorm.health.ts#L54-L56

In order to do this, @nestjs/terminus check whether these packages can be loaded with the CommonJS require function

https://github.com/nestjs/terminus/blob/0dfc7256dfc227ee3084108b8896d749008f78e9/lib/utils/checkPackage.util.ts#L32-L40

This results in multiple pitfalls:

• ESBuild, Webpack, Yarn PNP does not work with optionally loading packages #1423
• ESM will be difficult / impossible to support
• Health Indicator implementations tend to be more complicated than necessary within @nestjs/terminus
  • In order to ensure that no TypeScript build errors occur, only types of the third party library can be referenced internally. This will make sure that @nestjs/typeorm is never referenced in the *.d.ts files. Since not everyone uses the TypeOrmHealthIndicator we always have to assume that this package does not exist. Because of this, third party types can also not be exported.

https://github.com/nestjs/terminus/blob/0dfc7256dfc227ee3084108b8896d749008f78e9/lib/health-indicator/database/typeorm.health.ts#L6

https://github.com/nestjs/terminus/blob/0dfc7256dfc227ee3084108b8896d749008f78e9/lib/health-indicator/database/typeorm.health.ts#L62-L64

🔎 Implementation details

This RFC would try to minimally change implementations of the Health Indicators. The biggest change would be refactoring the different Health Indicators which require third-party dependencies. The following Health Indicators would need to be extracted to its own package:

• TypeOrmHealthIndicator -> @nestjs/terminus-typeorm
• SequelizeHealthIndicator -> @nestjs/terminus-sequelize
• MongooseHealthIndicator -> @nestjs/terminus-mongoose
• MikroOrmHealthIndicator -> @nestjs/terminus-mikroorm
• HttpHealthIndicator -> @nestjs/terminus-http
• MicroserviceHealthIndicator -> @nestjs/terminus-microservices
• GRPCHealthIndicator -> @nestjs/terminus-grpc

The other Indicators could remain in the @nestjs/terminus package. @nestjs/terminus would still hold the logic to execute Health Indicators as well as providing common functionality to write Health Indicators.

⬆️ Main benefits of this proposal

• Support for #1423
• ESM support
• Simpler implementations of Health Indicators within @nestjs/terminus

⬇️ Main downsides of this proposal

• More dependencies to install. For instance, in order to use the NestJS TypeOrm integration with Terminus, one would need to install the following packages: typeorm @nestjs/typeorm @nestjs/terminus @nestjs/terminus-typeorm.

💡 Mitigation: Consider adding nest add @nestjs/terminus-schematic where one could select the health indicator needed for the project. This schematic could possibly auto-select health indicator by parsing through the package.json. So if the @nestjs/typeorm is already installed, most likely the user would want to have a health check with that library.

• Hefty breaking changes

❓ Mitigation: Open for ideas how to make the upgrade process simpler?

• Mono repository setup required which makes the build process & CI/CD more difficult.

[BrunnerLivio]

This point seems to me the very most complex, at the moment I have never done tests with terminus with webpack to study the behaviors and how to solve the problem. You have done some tests about it ?

The problem most certainly lies in the code below. Essentially webpack can’t predict whether Terminus is loading a package or not. Splitting the HealthIndicators into a package each would solve this issue because Terminus wouldn’t need to load packages, the user would.

https://github.com/nestjs/terminus/blob/0dfc7256dfc227ee3084108b8896d749008f78e9/lib/utils/checkPackage.util.ts#L32-L40

For ESM support I think you need to evaluate if all official NestJS modules will support it then yes, otherwise it’s better not to think about it right away.

I am aware the ESM is not supported yet. I don’t think I could support ESM even if I wanted to at the moment due to third party packages. Nonetheless, it seems like ESM is coming no matter what. With this RFC I could support it when the time comes.

If there are other approaches to solve both of these issues I am very open for these suggestions. This RFC is just an idea to address these problems, though if I can avoid this additional complexity then I’d love to go with an alternative 😃

[Tony133]

Hi @BrunnerLivio, for these two points, I’ll answer you here below:

• Support for ESBuild, Webpack, Yarn PNP https://github.com/nestjs/terminus/issues/1423

This point seems to me the very most complex, at the moment I have never done tests with terminus with webpack to study the behaviors and how to solve the problem. You have done some tests about it ? Instead as regards ESBuild and PNP yarn are not yet “ready” for use (my opinion), they still need improvements and that resolve some incompatibilities, eg esbuild does not support typed declarations.

• ESM support

For ESM support I think you need to evaluate if all official NestJS modules will support it then yes, otherwise it’s better not to think about it right away.