How the creator of Homebrew simplifies distributing software with tea and Deno

This is a guest blog written by Max Howell, creator of Homebrew and founder/CEO of tea.

One of the biggest challenges with building open source software is the distribution — the build and release process, being able to support all major platforms, etc. This problem is something that we’re solving with tea.

tea, the spiritual successor to Homebrew, is a command-line universal interpreter, environment manager, and dependency manager that uses blockchain technology to compensate open source software maintainers. Since launching in November 2022, tea has over 10,000 users and is growing.

deno compile makes sharing software easy

As the creator of one of the most popular package managers for Mac, Homebrew, I understood that the biggest bottleneck for adopting open source software is distribution. I made the choice to write Homebrew in Ruby, as it came bundled with OS X, which meant that all users needed to do was clone the repository. When it came to tea, I was greatly inspired by Deno’s one-binary approach. Thanks to deno compile, I was able to write in TypeScript and compile it to a single binary.

Sharing Node or TypeScript applications is typically painful — users would need to have Node installed, clone or download the repo, run npm install, etc. Though there were npm modules that could help, such as pkg or nexe, they required additional configuration, especially for TypeScript projects.

With deno compile, you can compile your application into an executable that can run on major platforms with a single line.

Users can download the right binary for their platform and run tea from wherever they want to put it:

$ curl -Lo tea https://tea.xyz/$(uname)/$(uname -m)
$ chmod u+x ./tea
​
$ echo '# tea *really is* a standalone binary' | ./tea --sync glow
installing charm.sh/glow
pantries sync’d ⎷

   tea really is a standalone binary

Though hugely important in our distribution, deno compile is still one small part of our larger build and release process.

Build infrastructure made simple with Deno

Like most software on GitHub, we use GitHub Actions for the build and release process. All related scripts are written in TypeScript and run with Deno, and glued together with a bunch of GitHub .yaml.

Deno’s robust built-in toolchain for linting, typechecking, testing, and compiling, removes a ton of overhead.

— Max Howell

Here are main steps of our build and release workflow is as follows:

• Check if this version already published
• Check out repo
• Run tests with deno test
• Upload coverage
• Lint with deno lint
• Download artifact and run deno compile
• Bundle-src/ upload
• Release to various platforms

deno compile can take any TypeScript or JavaScript file and compile it into a single binary executable that can work on Windows x64, macOS x64, macOS ARM, and Linux x64. Deno’s toolchain also meant we spent less time evaluating and configuring third party frameworks with our workflow and more time building product.

Composable, self-contained Deno scripts as build infrastructure

tea makes it simple for users to access and download any open source software to any platform. There are many challenges involved in making downloading any package that works like magic into a single keystroke, such as getting artifacts, tagging, packaging and compressing packages, etc. We simplified this complex process by using composable, self-contained Deno scripts as build infrastructure.

Deno’s URL import system is modern, simple, web compatible, and doesn’t bring in the cruft from existing package managing systems.

– Max Howell

All of this happens in our build infrastructure repo, teaxyz/brewkit, which is a set of Deno scripts and yaml files. Deno’s web compatible (see importing by URL) and decentralized approach towards dependencies means there is no separate dependency manifest required (e.g. “package.json”) for each script. They’re self-contained and composable — each can be run anywhere with a consistent outcome, executed on its own, imported into another script, or executed in a series during the GitHub Action process, etc. — which makes it easy to debug, maintain, and update.

For an example, check out this script that compresses packages for GNU Privacy Guard, which uses yaml frontmatter to list dependencies, flags to pass to deno run, and specific environment variables.

Deno 🤝 tea

We’re happy building tea with Deno. Besides the points mentioned in this post, there are many parallels between tea and Deno that make Deno a great technology partner. We are both modern, spiritual successors, challenging status quo, aiming to re-define how something is done.

Are you using Deno or tea in production? Let us know on Twitter or in Discord.