Managing multifile book

Questions
1

Hi,

Is there any real reason to divide a big book into files/modules? If so, how to do it properly? In order not to throw Tinymist off the track, etc.

2

Could you specify what you mean by “throwing Tinymist off the track”? I’ve been using Tinymist with for different projects and I haven’t noticed much of a difference in multi-file projects.

The reason for me to do multiple files is just structure. I can focus on a chapter or a section at a time and finding what I’m looking for becomes easier. But it’s ultimately up to one’s workflow. If single file works for you, you don’t have to split.

3
  1. I mean, it’s good to hear that Tinymist has no problems with a multifile project.
  2. I don’t know whether it’s possible to optimize compile time using multiple modules.
4

I’ve recently created summaries for some master’s courses, where I’ve used subdocuments to, well, create the summary. The structure was as following:

main.typ // main file
preamble.typ // contains universal packages
sections/ // folder which contains all the sections/chapters
  - section1.typ
  - chapter1.typ
  - etc.

The preamble.typ file is as mentioned to include necessary packages used across all files (for example meander). In each section file, I add the line

#include "../preamble.typ": *

to include those!

In main.typ I load templates, set document metadata and build the general structure of the document:

#include "preamble.typ": *

// some stuff here

#include "sections/section1.typ"
#include "sections/chapter1.typ"
// etc.

Note that #include inserts content where it is called. #import loads only functions, modules and variables (as read-only).

5

Thanks! I’d like to know whether the modular structure has anything to do with workflow efficiency, like recompile times, etc.

6

I’ll have to preface by remarking I almost never had performance issues with Typst that led me to optimize performance times. In fact, the only exception I’ve faced was QR code generation, and it was such a punctual use case that I didn’t stop for long to think if the package could be implemented in a more performant way. I hear fancy long-format documents like theses may take longer to compile, but I haven’t written one in Typst.

That said, I wrote a lot of LaTeX documents back in the day, and there a multi-file architecture did help a lot with performance. The main reason is somewhat obvious: if compiling a 10-chapter document took 5 minutes, commenting out 9 of the chapters would reduce compile time to roughly 30 seconds. While drafting and rapidly iterating on the layout, that time gain was essential. This also helped with troubleshooting: since in LaTeX error messages suck, you often have to comment out parts of the code to find out where an issue originates. Being able to comment a bunch of lines rather than tens or hundreds of them at a time made that much easier.

And finally, there’s the benefit of reusability. Say you want to create a series of documents about a product you’re selling. A marketing brochure, a user guide and an internal design document. In all three, you want to have the same introduction. You could copy-paste the part of the file you want every time, but copying files is easier. Or you could even maintain all three documents in the same folder, so that every time you change the description you can compile the three documents and they are consistently updated.

All in all, I think in Typst the main benefit of multi-file projects is workflow efficiency. It may help optimization, but for most projects it isn’t the main driver.