How to raise warnings?

[CrossDark]

I have a function called element

#element[name]

And I want to raise a warning when “name” is not present in the separately imported CSV file

[JosephTao]

Typst doesn’t have a built‑in warning function at the moment, but there is a workaround: you can force a warning by using a non‑existent font name. For a more convenient wrapper, you may want to use the uniwarn package.

Example:

#import "@preview/uniwarn:0.1.1": warning

#warning("name not in csv file")

This will produce an unknown font family warning. It’s not the most elegant solution, but it’s at least usable.

[Y.D.X]

The font warning has caveats and not all caveats are documented in uniwarn’s README. See Pass things to stderr as errors or warnings | Tips on debugging Typst code, including the dark magic:

@Y.D.X

Solution C: Exploit the font not found warning.

#show list: it => {
  text(font: "[WARN]\n" + repr(it), "") // 👈
}
- A

warning: unknown font family: [warn]
list(
  tight: true,
  marker: ([•], [‣], [–]),
  indent: 0pt,
  body-indent: 0.5em,
  spacing: auto,
  children: (item(body: [a]),),
)
  ┌─ <stdin>:2:13
  │
2 │   text(font: "[warn]" + repr(it), "") // 👈
  │              ^^^^^^^^^^^^^^^^^^^

• Pros: Can be used any number of times at any place.
• Cons:
  • The backtrace only contains the call itself. No nested calls.
    This implies that it’s not worth encapsulating it as a function (unless you combine it with a eval(generated-code) hack).
  • The font name can only be strings. You may have to pack the value with repr or yaml.encode. (See the above sections.)
  • The font name is case-insensitve.
    You can circumvent this with the Label is not attached to anything warning, but that one will escape your strings, which means that you can’t wrap lines.

warning: label `label("[WARN] list(\n  tight: true,\n  marker: ([•], [‣], [–]),\n  indent: 0pt,\n  body-indent: 0.5em,\n  spacing: auto,\n  children: (item(body: [A]),),\n)")` is not attached to anything

You can subscribe to Support for emitting custom warnings · Issue #1322 · typst/typst · GitHub to wait for the builtin support. There was an attempt in 2023 (https://github.com/typst/typst/pull/1872), but the PR was closed because more foundational design work was needed to be done at that time.

AI/LLM summary of PR #1872

This pull request, #1872, aimed to add a warn function to Typst’s foundations, enabling script-generated warnings. Here is a summary.

Core Objective

The primary goal was to implement a solution for issues #1322 and #1276 by introducing a warn function that leverages the warning infrastructure from PR #1731.

Key Discussion Points

The central debate revolved around warning suppression to prevent spam from third-party packages, which led to several design considerations:

1. Suppression Mechanisms: Contributors discussed various ways to suppress warnings, including:
   • A mandatory key parameter for filtering.
   • Automatic key derivation from package names.
   • CLI flags vs. inline annotations (like #suppressWarnings "packageName" or a #nowarn function).
2. Implementation Challenges:
   • The initial warn function showed the code snippet from the warn call itself, not the original cause, due to using Spanned.
   • The #nowarn function, as prototyped, could only suppress manual script warnings, not built-in Typst warnings, and was considered “impure” as it globally disabled warnings.
3. Design Philosophy: The core team, particularly @laurmaedje, felt the suppression mechanism needed a more foundational design. They favored a local, syntax-level suppression system over the global, evaluation-phase approach taken in the PR.

Technical Feedback

Several specific code improvements were suggested and partially addressed:

• Using the warning! macro instead of manually constructing diagnostics.
• Fixing code style issues (indentation, nested imports).
• Adjusting test comments to match project conventions.

Final Outcome

Due to the significant design work still required, the PR was closed on November 21, 2023, without being merged. The maintainer, @laurmaedje, acknowledged the effort but stated that PRs are not the ideal venue for such foundational design discussions. A new topic was opened in the contributors’ forum on Discord to continue the conversation.

Status

The pull request is closed and unmerged. It has seen no activity since its closure, with users inquiring about progress as recently as May 2026, but it remains closed.