typst-examples-book is a rulebook for what belongs in a Typst example

The book is mdbook plus a custom Typst renderer

The build stack is three pieces and the third one is the interesting part. To compile the book you need the `typst` cli installed, `mdbook` and a highlighting and rendering preprocessor called `mdbook-typst-highlight`, which lives in its own repository. Assuming `typst` is already installed, the installation using cargo is:

cargo install mdbook
cargo install --git https://github.com/sitandr/mdbook-typst-highlight

You can alternatively install them precompiled from the `mdbook` and `mdbook-typst-highlight` releases, and in the end you have to have the latest versions of them all in your PATH. Once everything is installed, `mdbook build` builds the book, `mdbook watch` gives continuous rebuilding, and the `--open` option opens the book in your browser. The repository layout is small: a `book.toml` configuration at the root, a `src/` directory holding the content, and a `theme/` directory for the presentation layer. The primary language recorded for the project is CSS, which reflects that the theme is the hand-written part while the content is Typst.

The four rules decide what a snippet may contain and where it goes

The rules section is the part of the project with actual content, and it reads as a set of editorial decisions rather than boilerplate. The first rule is about credit. Many snippets are taken from Discord, Github or other places, and getting consent for every one would be a disaster, so as a general rule a non-trivial snippet, one that combines typst functions in a smart way, should have a credit to the original author, with the credit removed if the author objects. The second rule is about ordering. In the Typst by Example section, concepts that have not been told yet should be avoided if possible, although it is okay to use them if they are really intuitive or without them the demonstration would be too dull. The third rule says that Typst Snippets and Typstonomicon should not include stuff that is already present in official packages, and there should be a link to a package instead, with the exception that using a package as a tool is allowed when the package use is secondary or the idea of using it for that task is not obvious. The fourth rule sends giant queries and hacks to Typstonomicon rather than Typst snippets, even when they are super useful, because Typst snippets should contain code as clean as possible.

Two sections with two different ambitions, split by cleanliness

The rules make it clear that the book has at least two distinct sections with different purposes. Typst by Example is the teaching sequence, and its constraint is pedagogical: it introduces concepts in an order a reader can follow, so it may not use a concept before it has been explained. Typst Snippets and Typstonomicon are the reference sections, and their constraint is the opposite. Snippets should be as clean as possible, which is why the rule about official packages exists, since duplicating a package's contents in a snippet teaches nothing and rots quickly. Typstonomicon is where the difficult, long and clever work goes. The reason to have both is a realistic observation about Typst specifically, that the language is powerful enough that a single-line solution to a real problem is often a hack, and the book has decided to keep those away from the examples a beginner will read. That is a defensible editorial position and it is unusual to see it written down.

Contributions are welcome and the work list is specific

The contributing section is short and asks for both small and large work. If you have a snippet you want in the book, you are invited to create an issue, and pull requests are very welcome. Three kinds of contribution are generally encouraged: editing, meaning expanding examples and fixing bad language issues, selecting any really useful code examples from Discord and Github, and ideas, meaning any ideas on how to make the book more useful. A separate list names what is currently needed: help with updating the state manual to context expressions, updating examples with the possibilities of new Typst versions, and some impressive demos. There is also a coordination instruction that is worth reading before you start something large. If you think you can do some large work, you are asked to message the maintainer on Discord or by mail to avoid duplication, and the reason given is that the maintainer has bad memory. There is also a request to message the maintainer if a pull request is overlooked. In practice this means the project has a single coordinator and a small set of open tasks rather than a wide contributor base.

Cached Typst files have to be cleaned by hand before a rebuild

There is one maintenance operation documented, and it is a `git clean` invocation:

git clean -d -X -i

The documentation adds a warning to make sure you avoid deleting something useful. The command is the interactive form, with the `-i` flag asking before each removal, and the `-X` flag targeting only ignored files, which is what makes it safe to run against a tree that contains Typst build output. This exists because Typst caches compiled files, and a stale cache produces a book that does not match the sources. It is a small thing, but it is a real operational detail of the project: the build is not self-cleaning, and a contributor who has built the book before changing an example may find the output unchanged. The project structure with a `src/` directory and a `theme/` directory means the cache lives alongside the sources, and a selective clean is the documented remedy.

Where a curated example book is the wrong tool

Two limits are worth naming, and neither is a criticism of the work. The first is that it is a book, not a component. There is no package to install, no API to call and no behaviour to depend on, so it cannot be adopted the way a library is adopted, only read, and possibly contributed to. The second is that the content is a snapshot of one person's understanding of Typst at one moment, and Typst moves quickly enough that the rules themselves name this as a task, since updating examples with the possibilities of new Typst versions is listed as currently needed work. The alternative to weigh against is the official Typst documentation and package ecosystem, which is what the third rule points at for anything that already exists as a package. The difference in approach is that the book is deliberately full of the things a manual will not teach, including the slightly clever combinations that a reference would leave out, and that value depends on the coordinator keeping the examples current. A reader who wants an introduction can start with the book and move to the official packages for anything specific; a reader who wants an authoritative reference should skip it.

Editorial conclusion

typst-examples-book is worth reading if you are learning Typst, because every snippet is a small worked program rather than a fragment, and because the rules section tells you the reasoning behind the examples so the same ideas can be applied to your own documents. It is a poor fit if you want a Typst package or a library, since it is a book rather than code you depend on, and a poor fit if you want a reference manual, since the rules state that official package content should not be duplicated and should instead be linked. Before contributing a snippet, read the rules, because the credit requirement and the section split are enforced by convention rather than by a checker, and note that the last push to the repository was on 2026-10-16 with no tagged releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. sitandr/typst-examples-book on GitHub