Fira Code: the arm64 build installs three stub packages, and the last release is from 2021

The README downloads release 6.2, dated December 2021, and nothing newer is tagged

The Download and Install section is a single link, and it points at a fixed artifact: the Fira_Code_v6.2.zip from the 6.2 release. The three most recent release tags are 6, 6.1 and 6.2, published on 2021-11-29, 2021-12-03 and 2021-12-06, all inside one week. The last push to the default branch is dated 2026-07-28. So the newest downloadable build is from December 2021 while the repository has carried close to five years of commits that were never cut as a release, and the package manifest still declares version 6.2.0. Consequence for a reader: installing exactly what the README tells you to install gives you a font built before most of the repository's history, and the gap is invisible unless you compare the tag date against the commit date yourself. The changelog exists as a file in the root, but the update channel the README points to is a social account, not the releases page.

On arm64 the build installs three stub packages carrying real names and versions

The container image is python:3.12, and it has one conditional block that is worth reading closely.

ARG TARGETARCH
RUN if [ "$TARGETARCH" = "arm64" ]; then \
        for stub in "resvg-cli 0.44.0" "opentype-sanitizer 9.2.0" "pngquant-cli 3.0.3"; do \

The comment above the block explains the reason: unused transitive deps without arm64 wheels. What the loop then does for each name and version is create a directory, write a minimal pyproject.toml containing only a project name and a version, install that, and delete the directory. So on arm64, resvg-cli, opentype-sanitizer and pngquant-cli are satisfied by empty stand-ins that carry the real package names and the real version numbers. Consequence: a build on Apple Silicon runs without the rasterizer, the font sanitizer and the PNG optimizer, and pip reports all three as installed at the correct versions. Nothing in the build output distinguishes a real run from a stubbed one, so an arm64 build can differ from an x86 build with no error raised.

The Makefile has no local build target and pulls a floating image tag

The whole build interface is three targets.

all: build

build:
	docker run --rm -v ${PWD}:/opt tonsky/firacode:latest ./script/build.sh

package:
	./script/package.sh

There is no local path. The build target shells out to Docker, bind-mounts your current directory at /opt, and runs a script inside a published image. The image reference ends in the tag latest, which is the one tag guaranteed to be repointable, and nothing in the Makefile pins a digest. The package target, by contrast, is local, so the two ways of producing a package do not share a reproducibility story. Consequence: two people running make build on different days can execute different toolchains under the same command, and because the working tree is mounted rather than copied, whatever the container writes lands in your checkout with the file ownership of the image's user. Reproducing a specific published build means identifying the image yourself, not reading the Makefile.

Ligatures are a rendering feature, so a copied snippet arrives as plain characters

The Solution section is where the design decision is stated, and one sentence settles it: this is just a font rendering feature, underlying code remains ASCII-compatible. The Problem section sets up why, noting that a human reads sequences like `->`, `<=`, or `:=` as single logical tokens even when they take two or three characters, and that the eye spends a non-zero amount of energy joining them. The file also says that for frequent sequences like `..` or `//`, ligatures allow correct spacing. Consequence for a reader: everything downstream of your screen operates on the unligated characters. A snippet you copy, a diff you paste, a search for an operator, a terminal selection and a file saved from the editor all contain the original ASCII, so a colleague without the font sees exactly what you see, and the ligature cannot be searched for because it does not exist in the text. For the spacing cases the rendered width also differs from the character count.

Several ligature sets are off until a stylistic set is enabled, and the default is not stated

The file lists what the font carries without saying what is on. There are character variants named cv01, cv02 and so on, stylistic sets named ss01, ss02 and so on, and other font features named zero, onum, calt and so on, with a wiki page titled How to enable stylistic sets. Then a separate paragraph says some ligatures can be altered or enabled using stylistic sets and character variants. Read those two together and the headline feature is partly opt-in. Consequence for a reader: you install the font, an editor that does not expose OpenType feature toggles shows you a working font with no ligatures, and the file does not state the default set so you cannot tell whether a missing ligature is a configuration problem or simply not in the default. The features live in a features/ directory, so the toggles are data, and the README describes them only by OpenType feature code.

A font cannot be feature-detected, so progress bars ride on an environment variable

Fira Code is described as the first programming font to offer dedicated glyphs to render progress bars, and the implementation note is the interesting part. There is no way for programs to detect whether a font has progress bar glyphs at U+EE00, so a program has to decide what to output without knowing whether it will render properly. The proposal is a new environment variable, `UNICODE_PROGRESS_BAR=true`, to be used as a heuristic, and if it is present it is safe to assume U+EE00..EE0B will render properly. Consequence: the failure runs in both directions and neither is visible. A user with Fira Code who never sets the variable gets ordinary box-drawing characters instead of the joined glyphs, and a user with a different font that also has those glyphs has no reason to set it. The switch is a convention that a terminal program has to opt into, so the font's most distinctive feature depends on software you do not control.

KDevelop and UltraEdit each sit in both columns of the compatibility table

The editor compatibility table has a Works column and a Doesn't work column, and two entries appear in both. KDevelop 4 is in the failing column while KDevelop 5+ is in the working one, and UltraEdit on Windows is in the failing column while UltraEdit (UEX) on Linux is in the working one. Reading down the working column, several entries depend on something outside this repository: Brackets needs a plugin hosted elsewhere, Xcode needs a third-party plugin unless you are on 8.0 or newer, and the instructions for Notepad3, VimR and gVim point at issue trackers and wikis on other projects. Anjuta is listed with the caveat unless at the EOF, and Spyder IDE is marked only with Qt5. Consequence: searching the table for one editor can return a contradiction without reading both cells, and a row that says it works may rest on a plugin repository that can disappear independently of the font.

The source is a Glyphs file and a Clojure project, while the requirements file is Python only

The repository's primary language is reported as Clojure, and the root carries a clojure/ directory alongside a deps.edn, which is the Clojure CLI project descriptor. Outlines live in FiraCode.glyphs at the top level, a project file belonging to the macOS editor Glyphs. The build dependencies are declared in a Python requirements file, and every one of the six is pinned to an exact version.

fontmake==3.12.1
glyphsLib==6.13.1
gftools==0.9.997
fontbakery==1.1.0
ufo2ft==3.9.0
uharfbuzz==0.55.0

The Dockerfile is python:3.12 and installs only that file, with no JVM in the base image. There is also a googlefonts-qa/ directory and an npm manifest whose main is a stylesheet. Consequence for a contributor: the toolchain spans a Python font stack, a JVM-hosted Clojure project and a proprietary outline format, and the requirements file is silent about the middle one, so the Docker image is not a complete description of what a build needs. The exact pins also mean a rebuild years from now depends on those six versions still resolving.

Editorial conclusion

Fira Code is worth using if you want programming ligatures and do not need your pasted text to carry them, because the underlying characters stay ASCII and every editor, diff and search works on those. Read the wiki page before assuming a missing ligature is a broken install, since several ligature sets are off until a stylistic set is enabled. If you are building it yourself, note that the Makefile has no local path, the image tag floats, and an arm64 build substitutes stubs for three validation tools, so prefer an x86 build when the output has to match a release.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes