Packages · Tooling

`@notifkit/provider-console`

A transport that sends nothing. It prints the message and reports success, which is what you want in development and in tests — no API key, no network, no real recipient. It has no dependencies at all.

npm install @notifkit/provider-console

import { NotifkitServer } from "notifkit";
import { ConsoleTransport } from "@notifkit/provider-console";

new NotifkitServer({
  services: ["all"],
  providers: [
    new ConsoleTransport({ channel: "email" }),
    new ConsoleTransport({ channel: "sms" }),
    new ConsoleTransport({ channel: "push" }),
  ],
});

Options

Option	Required	Notes
`channel`	no	Defaults to `push`, not to every channel. One instance serves one channel.
`logger`	no	Also emits a structured log line, if you would rather read that than the banner.
`limits`	no	Unset by default — no throttling.

one instance is one channel

The commonest way to lose an hour with this package: constructing it with no arguments, expecting a catch-all, and finding that email still fails with no transport registered for channel. The default is push, and the registry keys on channel — so covering three channels in development means three instances, as above.

Its banner also reads PUSH NOTIFICATION whatever the channel is, so an email printed by it is labelled as a push. Read the channel field on the structured log line rather than the box.

What it prints

┌─────────────────  📲  PUSH NOTIFICATION  ─────────────────
│ to token : alice@example.com
│ recipient: usr_123
│ priority : normal
│ content  : {"subject":"Welcome","text":"Hi Alice"}
│ taskId   : 0f8c2b7e-…
└───────────────────────────────────────────────────────────

Every send returns { success: true } with a synthetic providerMessageId of console-<timestamp>. There is no failure path — which is the point in development, and the limitation in tests.

for tests, capture instead of print

This transport is for watching a send happen by eye. A test wants to assert on one, which means a transport that records into an array rather than writing to stdout — and one that can be made to fail, so you can exercise a fallback chain. Testing has one to copy, along with why a bare assertion straight after notify() always fails.

not for production

Because it always reports success, registering it in production means every message is logged as delivered and none is sent. It is worth being deliberate about which deployments construct it — a stray ConsoleTransport at a higher priority than your real one silently swallows the channel, and the delivery log will tell you everything went out fine.