Nix flakes allow to include system dependencies from software that are not published on the nix packages repository but that are themselves flakes. This post will explain how to achieve this.

Context

We would like to create a document using the new markup language named typst. Typst presents itself as a markdown like language that produces pdf; moreover, typst promise to be as powerful as latex.

Nix is the weirdest software I have worked with. After about a year of playing with it, I am still unsure if I should continue with my experimentations. Nonetheless, if you are interested to build a yarn project with nix, I will explain my solution.

To improve the readability of this post, there is an example project (yarn-nix-example) that demonstrates the idea.

yarn-nix-example is a basic node/yarn project that builds a static website using parcel. The root directory contains a package.json and a yarn.lock file. The traditional way to build the project is to use yarn install to fetch all the dependencies and create a node_modules directory. Then yarn build (defined in package.json) delegates to parcel the compilation of the typescript assets into a standalone javascript file.

Introduction

We are in 2023 and my world still evolves around CLIs¹. I enjoy looking at my terminal and piping commands together. Knowing how to do stuff with CLIs is empowering and gives the impression of really understanding how things are built under the hood.

At work, I like to create a CLI where I put all my utilities bundled in a single executable. Usually, the CLI starts as a bunch of aliases and evolves into a complex tool that is used by many people.

It happens often that we need to implement an endpoint that returns a list of items with a “canonical” id. A typical example is a /users endpoint that returns a list of users.

In this post, I will advocate for returning a list of objects each of which contains an id key and not a single object where ids are associated with their canonical values.

// Good
[
    {id: 1, name: 'Emelia', age: 12},
    {id: 2, name: 'Cassidy', age: 96}
]

// Bad
{
    1: {name: 'Emelia', age: 12},
    2: {name: 'Cassidy', age: 96}
}

Communicate Intent

The first reason to return a list of items is that, semantically, it is what the endpoint returns. In API designing, communicating intent is of paramount importance. We should make sure intent is well communicated before considering any other API feature such as performance.