One diagnostic from qunitx itself: which files a narrowing flag scoped the run to, a filter that matched nothing, a build error, a timeout.
Distinct from a test result, and distinct from the program failing — a notice is qunitx
explaining what it did. The CLI renders these as TAP # comments, which is what they have
always been; a programmatic caller reads them as a list.
const notice: Notice = { level: 'warning', message: 'No tests matched --filter "Crat"' }; notice.level; // 'warning' — an 'error' additionally goes to the error stream
level: "info" | "warning" | "error"
info is a decision, warning a surprise, error a diagnostic that also hits stderr.
message: string
The text, already colored where the CLI colors it, with no # prefix and no newline.
raw: boolean
Write message verbatim rather than as a # -prefixed comment. For pre-formatted blocks —
the coverage table, a stack trace — whose own layout is the point.
stream: "output" | "error" | "both"
Which of the run's two streams the default rendering goes to; output by default.
Separate from level because the two answer different questions: level is what kind of
thing this is, which is what a consumer filters on, while this is where the CLI has always
put it. A raw stack belongs on error alone — un-prefixed multi-line text on stdout would
corrupt the TAP document — and a few diagnostics go to both deliberately, so a reader
watching only one stream still sees them.