Typst’s whitepaper—Fast Typesetting with
Incremental Compilation—asserts that it will use incremental compilation. As I was interacting with it, I realized that besides the PDF it produces, there is no other artifact that helps recompilation from previous compilations. Would you please help me find how Typst uses previous artifacts to compile when we make minor changes?
As far as I know, Typst’s incremental compilation is very fine-grained and is limited to within a single Typst session (e.g., calling typst c xxx.typ separately before and after editing won’t yield any benefits, while using typst watch xxx.typ before editing and keeping it running will). Therefore, the “artifact that helps recompilation from previous compilations” actually exists in memory but is not persisted to disk.
As for what form these in-memory “artifacts” take and how Typst leverages them for incremental compilation, you can refer to the whitepaper you mentioned and the comemo crate that Typst uses.
3 Likes
Hello.
Additionally, there were discussions about creating a Typst server that can handle multiple Typst clients, and one of the main features is to save the cached state so that if you want to compile to PDF, PNG, SVG, and HTML, you would have to compile the document once, and only spend time on exporting to different formats, which is not hard, so it’s supposed to be instant. But I don’t think there is an issue created for it. So without something like this, you can’t export the cache. Though in theory this should be possible. Just no one has done this.
The ever-awesome tinymist has in a way already done this; it also keeps the cached state in memory, and it has LSP commands for exporting PDF and PNG and more.