mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
Maurice
ac96644508
Four files taken apart rather than moved, because they only worked as a knot. The mailer becomes its own leaf module. AuthService sends the password-reset mail while NotificationsModule imports AuthModule for the demo gate in NotificationsMcp - a mailer inside the notifications domain would have closed a hard cycle that only a forwardRef could open again. Webhook and ntfy stay with notifications; auth has no business importing them. The channel registry stays a module singleton and does NOT become a provider. PluginRuntimeService pushes its channel getter in at onModuleInit, and notifications.bridge.ts builds its own NotificationsService for the scheduler crons and the memories senders. A provider would hand the bridge a second, empty registry - every plugin channel would then go quiet with no error anywhere. CHOVR-015 drives that seam end to end: a channel published through the runtime, delivered through the bridge. Nothing pinned it before; the existing cases all set the source themselves. The built-ins no longer self-register by side-effect import. They used to exist only because notificationPreferencesService happened to `import './notifications/builtins'`; removing that line would have silenced email, webhook and ntfy without a failure. They are built from the injected transports and registered from NotificationsService's constructor, so both instances have them. No cached nodemailer transport: MailerService.createTransport re-reads the SMTP config and skipTlsVerify per send, exactly as the three inline call sites did, so an admin changing them does not have to restart. Preferences become a provider over DatabaseService. Eight places built NotificationsService by hand, so a tests/helpers/notifications.ts factory keeps the next constructor parameter a one-file diff instead of an eight-file one.
32 lines
1.4 KiB
TypeScript
32 lines
1.4 KiB
TypeScript
import { DatabaseService } from '../../src/nest/database/database.service';
|
|
import { RealtimeService } from '../../src/nest/realtime/realtime.service';
|
|
import { MailerService } from '../../src/nest/notifications/mailer/mailer.service';
|
|
import { NotificationPreferencesService } from '../../src/nest/notifications/notification-preferences.service';
|
|
import { NotificationsService } from '../../src/nest/notifications/notifications.service';
|
|
import { NtfyService } from '../../src/nest/notifications/transports/ntfy.service';
|
|
import { WebhookService } from '../../src/nest/notifications/transports/webhook.service';
|
|
|
|
/**
|
|
* A NotificationsService wired the way Nest wires it.
|
|
*
|
|
* The domain takes six providers since the fold, and eight places used to build
|
|
* it by hand — every added constructor parameter was an eight-file diff. One
|
|
* helper keeps that at one.
|
|
*/
|
|
export function makeNotificationsService(dbs: DatabaseService, realtime = new RealtimeService()): NotificationsService {
|
|
const mailer = new MailerService(dbs);
|
|
return new NotificationsService(
|
|
dbs,
|
|
realtime,
|
|
mailer,
|
|
new WebhookService(dbs),
|
|
new NtfyService(dbs),
|
|
new NotificationPreferencesService(dbs, mailer),
|
|
);
|
|
}
|
|
|
|
/** The preferences half on its own, over the same connection. */
|
|
export function makeNotificationPreferencesService(dbs: DatabaseService): NotificationPreferencesService {
|
|
return new NotificationPreferencesService(dbs, new MailerService(dbs));
|
|
}
|