Current behavior
SentryModule is decorated with @Global() and exports SentryService:
@Global()
@Module({
exports: [SentryService],
imports: [ConfigModule, EnvironmentModule, LoggerModule],
providers: [SentryService],
})
export class SentryModule {}
However, SentryService is not injected in any other module — it is only referenced within the sentry module itself. So the @Global() decorator provides no practical benefit here.
On the other hand, LoggerModule exports LoggerService, which is consumed by several modules (AppModule, PrismaModule, RedisManagerModule, ShutdownModule, and SentryModule), each of which currently has to import LoggerModule explicitly. Yet LoggerModule is not marked global:
@Module({
exports: [LoggerService],
imports: [EnvironmentModule],
providers: [LoggerService],
})
export class LoggerModule {}
Proposal
Move the @Global() decorator from SentryModule to LoggerModule. This matches the intended use case of a global module (a provider needed across many modules) and would allow the repeated LoggerModule imports to be removed. It also makes the codebase a clearer reference for learners studying when @Global() is appropriate.
Current behavior
SentryModuleis decorated with@Global()and exportsSentryService:However,
SentryServiceis not injected in any other module — it is only referenced within thesentrymodule itself. So the@Global()decorator provides no practical benefit here.On the other hand,
LoggerModuleexportsLoggerService, which is consumed by several modules (AppModule,PrismaModule,RedisManagerModule,ShutdownModule, andSentryModule), each of which currently has to importLoggerModuleexplicitly. YetLoggerModuleis not marked global:Proposal
Move the
@Global()decorator fromSentryModuletoLoggerModule. This matches the intended use case of a global module (a provider needed across many modules) and would allow the repeatedLoggerModuleimports to be removed. It also makes the codebase a clearer reference for learners studying when@Global()is appropriate.