taproom: a terminal browser for Homebrew, with the dependency tree already loaded

The problem: brew gives you one package at a time

taproom is a cozy terminal user interface for Homebrew, a fast and fluid way to explore formulae and casks directly in your terminal. The project was featured as Tool of the Week on July 15, 2025 on Terminal Trove.

The highlights section explains the design in terms of what the Homebrew command line makes you do. Search in taproom gives results with all the details in real time, while using brew you need to run brew search and then brew info on each package.

That is the core friction. The Homebrew CLI is a collection of narrow commands, and the questions you actually have when you are looking at a package are broad. Will this install something I already have? What does it depend on that I do not have? What would this cost on disk? Who else needs this? The CLI answers each with a separate invocation and a separate output format, and the dependency question in particular is the one that gets slow.

The dependency handling is where taproom differs most. brew info shows direct dependencies, while taproom also shows all recursive dependencies that are not installed, and the documentation says this is helpful to understand what exactly would be installed as dependencies. It also has a clear indication for packages installed as dependencies versus installed explicitly, which is a distinction the CLI does not surface in a list.

The dependents view is the other one. brew uses --eval-all shows dependents that require the target package, but it is a pretty slow command, while taproom has this information available without additional data loading.

So the pitch is not that the TUI is prettier. It is that the metadata is loaded once, in parallel, and then every view of it is instant.

Search prefixes, and the one that changes how you query

The search feature is where the TUI earns a second look, because the query syntax is more precise than anything the CLI offers.

By default, the search matches each keyword in either the name or the description. Then there are field prefixes. The n: prefix matches the keyword only in the name, d: matches only in the description, t: matches only in the tap, and h: matches only in the home page.

The tap prefix is worth understanding. In Homebrew, a formula can come from a third-party tap rather than from core, and the tap is where the source lives, so searching by tap is a way to answer which of my tapped packages provides this tool. The home page prefix is a narrower version of the same idea, matching against the URL the package points to.

The last prefix is the one that changes behaviour rather than narrowing the field. A - prefix turns the keyword into a negative keyword, and it can be combined with the field prefixes. The example given is `ebook -facebook`: search for ebook but not facebook.

That combination is genuinely useful in a way that substring matching is not. On a machine with a large cask catalogue, searching for a tool by a common word gives you dozens of near matches, and the only way to narrow them in the CLI is to read the output. Here you can say what you do not want, and the negative term can be scoped to a field, so a negative name match and a negative description match are different queries.

The sorting options are also more than alphabetical. The tool supports sorting by popularity, which is the 90-day install count, and by size, which is the disk space used. Sorting by size is the one that is genuinely novel, and it is how you find the package quietly eating a hundred gigabytes.

Running brew commands from inside the table, and the dependency data behind it

The features section covers the parts of the interface that are less obvious from a screenshot.

The table view is an overview of all available formulae and casks in Homebrew. The detailed view gives more info on any package, including its description, version, homepage, license, dependencies and 90-day install count, and also shows dependencies recursively when they are not installed, and also shows dependents, which other packages depend on this one.

The filters narrow the list: all packages, or formulae only, casks only, installed packages, outdated packages, and packages you installed explicitly rather than as dependencies. That last filter is the useful one, because installed-as-dependency packages are the ones you did not choose and often do not recognise.

Status indicators show at a glance which packages are installed, outdated or pinned, and the tool can execute brew commands directly: upgrade, install, uninstall, pin or unpin. So the TUI is not a read-only browser, it is a front end to the same commands you would type, which means the muscle memory transfers.

Navigation is keyboard based, and two keys are documented: h opens an app's home page and b opens the brew formula page. The build from source section confirms the tool has a nerd font requirement, which is the same requirement a full-screen TUI has for box drawing and icons.

The dependency data comes from Homebrew's own metadata, and the tool caches it. The --invalidate-cache flag, or -i in short, invalidates the cache and re-downloads data from brew.sh, which tells you the data comes over the network rather than from a local brew command, and that a stale cache is the failure mode to expect.

Flags, the theme auto-detection, and the column hiding trick

The customization section is a list of command line flags, and two of them are worth calling out.

The first is --hide-columns, which hides and skips loading data for specified columns. The explanation is the interesting part. While all data loading is done in parallel, some may be slower than others, and this flag can be used to skip loading certain data to speed up app load.

That is a real insight about how the tool is built. The expensive fields, the ones that come from a remote call per package such as the release date, are fetched in parallel with the cheap local ones, and the total load time is set by the slowest of them. So rather than making the slow call faster, you make it optional, and the flag is how you skip it. For a user who does not care about release dates, that is the difference between a fast launch and a slow one.

The second is --theme, which takes auto, light or dark with auto as the default. By default, taproom auto-detects your terminal's background color and picks a matching palette, and the documentation says to use --theme light or --theme dark to override if auto-detection does not work for your terminal. Terminal background detection is a genuinely hard problem across emulators, so having an override is not an optional extra.

The other flags are more conventional: --fetch-release for release information, which also enables the r key to open the release page, --load-timer or -t to show a timer on the loading screen, --hide-help to hide the help text at the bottom, --sort-column or -s to pick the sort column, and --filters or -f to set the initial filters. The sort and filter flags set the initial state, and both can still be changed in the app with the s and S keys.

The --fetch-release flag has a documented limitation. Release information is only available when the homebrew URL or home page points to a GitHub repo with releases, and about 60 percent of packages would show the release date. It needs the gh CLI in the PATH.

Building and shipping it, and what the dependencies say

Installation is a Homebrew tap or a GitHub release download:

brew install taproom

Or with eget, which fetches a release binary straight from the GitHub repository:

eget hzqtc/taproom

Building from source needs Go, and the steps are a make and a run:

make

and then ./taproom. The Makefile is a small and conventional Go project file. The build target runs go mod tidy and then go build, and the install target sets GOBIN to a local bin directory under your home before running go install. The release target cross-compiles for darwin on arm64 and amd64, tars each binary, and generates a checksum file with shasum. The gh-release target tags the version from the .version file, pushes the tag, and creates a GitHub release with the gh CLI.

The dependency list is short and tells you the shape of the thing. The three Charm libraries do all the work: bubbletea for the event loop, bubbles for the text input and viewport components, and lipgloss for the styling. The x/ansi package handles ANSI escape sequences, pflag is the command line parser, and pkg/browser opens a URL in the default browser, which is what the h and b keys use.

The indirect list is where the terminal handling lives. The runewidth, uniseg, stringish, uax29 and displaywidth packages are all about computing how wide a string renders, which is the thing every TUI has to get right with emoji and CJK text, and go-osc52 is the clipboard integration that lets you copy a selection out of the terminal.

The module targets go 1.24.4, and the licence is MIT.

How it compares to boldbrew, and what taproom still does not do

There is an alternatives section, and it is short and specific. taproom is inspired by boldbrew but it is not a clone, and then the differences are listed.

taproom has a different UI style, supports casks, supports sorting by different columns, shows missing dependencies recursively, that is dependencies of dependencies, shows reverse dependencies, that is used by, which replaces a very slow brew uses formula --eval-all command, and shows the size of installed packages.

Every one of those is a specific behavioural difference rather than a claim about taste, and the boldbrew comparison is worth noting for a particular reason. If you already know boldbrew, taproom is a familiar shape with a different set of trade-offs, and the differences that matter are the cask support and the dependency depth.

What taproom does not do is replace brew. The tool executes brew commands, it reads Homebrew's own metadata, and it needs brew installed. It is a front end to the package manager, not a package manager.

The dependency requirements are also worth stating plainly, because they are easy to miss. A terminal emulator with a nerd font, the du command which the documentation lists as a MacOS builtin, brew itself, and the gh GitHub CLI, which is optional and only used for getting release info when the --fetch-release flag is set.

The du requirement is the one that catches people. The size sorting and the size column are computed by shelling out to du on the installed package directories, which is why the tool needs the disk usage utility present even though it is a Go program and could have implemented the calculation itself. It is a small design choice with a real dependency cost, and it is the kind of thing you only notice after installation fails on a machine with a minimal userland.

Editorial conclusion

Adopt taproom if you install Homebrew packages regularly and want to see what a formula would pull in before you install it, since the recursive dependency and dependent views are the reason it exists. Do not adopt it on a machine without a nerd font or without the du command, because the interface needs both, and expect Homebrew itself to remain your installation tool rather than a replacement. Before you rely on it, check that the cached package data is fresh enough for your needs, since the tool downloads metadata from brew.sh and offers an invalidate-cache flag for when it goes stale.

Frequently asked questions

Official sources

1. hzqtc/taproom on GitHub
2. Issues
3. License: MIT
4. README
5. Releases