Creator of Homebrew simplifies distributing software with tea and Deno
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 binaryThough 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.
