Install kuto with Homebrew

Project links

• Homepage
• Upstream docs
• Package manager page

Commands and aliases

• kuto

Project history

Sam Thor published Kuto publicly with a March 2024 explanation of the idea: split a built JavaScript bundle into a main file plus cacheable corpus files, then reuse unchanged corpus code across later builds. The README says the `kuto info` command came first as a way to inspect ES modules for side effects.

Adoption history

Kuto is a niche web-performance tool rather than a mainstream bundler replacement. Its own documentation frames it as a final pass after another bundler and asks users for real-world results, which matches a young experimental tool.

How it is used

The CLI is used after bundling: `kuto split` reads a large ESM output file, writes a main part plus static corpus files, and can use previously generated output as the old corpus for later builds.

Why package nerds care

Kuto is interesting to package and web-build-system nerds because it reverses the usual bundling assumption. Instead of making one fresh optimized artifact per build, it tries to preserve previously shipped code as a reusable cache dictionary.

Timeline

• March 2024: Maintainer published the reverse-bundler write-up and linked it from the project README.
• Initial design: `kuto info` originated as an ES module side-effect inspection command before the split workflow.

Related projects

• Kuto is designed to run after conventional JavaScript bundlers, and its README demonstrates a release process that uses esbuild before and after Kuto.

Sources

• https://github.com/samthor/kuto
• https://samthor.au/2024/kuto/