Developer tooling

tooling

A small tool is sustainable when building, testing, and releasing it doesn't take extra work.

Figure

fig. 1 — A darkroom session. Each prompt has the model that answered it, what it cost, and the file it wrote beneath it. The next prompt edits that image.

Project note

Command-line tools in one monorepo. The first is darkroom, a terminal studio for making and editing images across 58 models, with the cost of each one shown.

The problem

Small command-line tools often start as one-off scripts. Turning one into something other people can install means a build, tests, a version, a changelog, and a release process. That overhead is why most of them never leave script form.

The approach

tooling keeps every tool in one pnpm monorepo. Each tool has its own directory, version, changelog, and npm package. Private libraries hold the code the tools share, and each tool bundles them in when it builds. A generator creates a new tool with its scripts, a first test, and a README already in place.

Releasing is one command. It builds the tool and commits the version, then pushes a tag. The tag starts a workflow that checks the tag against the package and waits for CI. It then writes the release notes and publishes to npm with provenance. The GitHub release comes last.

The tools run on Bun or Node. They use Node APIs only, so they behave the same on both.

darkroom

The first tool is darkroom, a terminal studio for image generation. Describe an image and pick one of 58 models. Each result appears in the session next to the model that made it and its cost. The saved file path appears too. A follow-up prompt edits the last image with a model that can edit. Sessions, history, and the model list each have their own tab, and darkroom --continue picks up where you left off.

What it demonstrates

One release pipeline shared by every tool, from tag to npm.
A terminal interface for a workflow that’s often a web app.
Lint, test, and build configuration shared across a monorepo.