Skip to content

Add Typst Package so .cook files can be imported to Typst#84

Draft
padalev wants to merge 2 commits intocooklang:mainfrom
padalev:feature/typst-package
Draft

Add Typst Package so .cook files can be imported to Typst#84
padalev wants to merge 2 commits intocooklang:mainfrom
padalev:feature/typst-package

Conversation

@padalev
Copy link

@padalev padalev commented Dec 15, 2025

I have been thinking a bit more about how to best create formatted Recipes and Cookbooks from cooklang .cook files using Typst.
This has already been discussed in cooklang/cookcli#176, cooklang/cookcli#192, cooklang/cookcli#197 and cooklang/cookbook-creator#1.

Up until now the chosen approach was always to programmatically create a typst file which would then be compiled by the typst compiler. This approach, however, is strongly discouraged by the developers of Typst (https://typst.app/blog/2025/automated-generation).

The more idiomatic solution from the perspective of Typst would be to import the data (here: .cook files) into the Typst document and then define the Layout there. This is possible as Typst offers extensive scripting capabilities.

One approach here that is possible right now would be to write an external script that uses the CookCLI (https://github.com/cooklang/cookcli) or the cooklang package to convert recipes to json, then when invoking the typst compiler hand the json over and in the typst file interpret that json.
There is, however, also the "Typst Universe", a collection of Typst packages provided by the community. I think it would be nice if a cooklang package would be available that can convert .cook recipe files to a Typst dictionary (Typst does not offer advanced object structures).

This PR provides such a package. It is in fact quite simple:
The parsing is handled in a WebAssembly library that uses the existing Rust Library.
The resulting recipe is converted to json for interfacing with Typst code (The Typst compiler requires that wasm libraries can only accept and return bytes).
The Typst wrapper then converts the json to a Typst Dictionary.

The advantage of this approach is that maintenance is reduced since the parsing is handled by the main Rust framework.
For users the main advantage is that no additional external scripts are needed. Everything needed for document assembly and formatting can be done from within a Typst document. This also keeps the formatting directly accessible to the user, which makes a lot of sense as I see things.
I have created a simple example document in the examples folder.

In the future it would be nice to add the ability to search a directory for .cook files and provide the user with a recipe tree of sorts. This is currently not possible as such access is not yet provided by Typst. There is however strong interest in "Directory Walking" from the Typst community and the Developers seem to be actively working towards enabling this functionality in the future (typst/typst#2123)

There are a few things that need to be done still:

  • Documentation
  • Error handling inside the wasm library. For testing I have used unwrap, which can obviously not stay. No std output is available so I guess a special error json of some sorts would have to be handed back to the Typst wrapper. Any suggestions?
  • Possibly the data structure could be simplified? I'm not sure if that would even make sense, since the json format is already structured like that for a reason.

In case it is decided to submit the package to the "Typst Universe", there is guidelines for submission: https://github.com/typst/packages/blob/main/docs/README.md
Essentially submission works by creating a PR on their Repository.
The name of the package should in general not be canonical or obvious for reasons of fairness. I believe, however, that if it is somehow "official" the package could just be called "cooklang" which I think would be nice. I guess the PR would then have to be created by an account associated with the cooklang project, however.
This is also the main reason I'm creating this as a PR for this repository instead of just creating a separate repository myself.
It also seemed to me to fit, as the typescript implementation works quite similarly, for example.

@pkg-pr-new
Copy link

pkg-pr-new bot commented Dec 16, 2025

commit: 4006c07

@dubadub
Copy link
Member

dubadub commented Dec 16, 2025

Looks good, thank you. I can publish it when it's ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants