react/yoga: Chrome is the oracle, and the newest tag is from December 2024

The repository description says layout engine, the README says flexbox

Two descriptions of the same project sit in different places and they are not the same width. The repository description calls Yoga an embeddable layout engine targeting web standards. The README calls it an embeddable and performant flexbox layout engine with bindings for multiple languages.

The second is narrower and more accurate, and the distinction matters if you are choosing a tool. Flexbox is one layout model, not a general solver for block flow, tables, floats or grid. An engine described as targeting web standards sounds like a general conformance target, while an engine described as flexbox is a fast implementation of one part of it.

The primary language in the repository is C++, which is the part the README leads with. The organisation it lives under is the React one, and the homepage is yogalayout.dev, but the README does not talk about React at all: it covers building, adding tests, the vcpkg port and debugging. What follows from that is that the bindings are consumers of a C++ library, and the language specific packaging lives in the tree rather than in the README.

The expected layout in every generated test is whatever Chrome produced

This is the most consequential thing in the README and it is stated in three sentences. Many of Yoga's tests are automatically generated, using HTML fixtures describing node structure, and those fixtures are rendered in Chrome to generate an expected layout result for the tree. New fixtures are added to a fixtures directory inside the test generator.

<div id="my_test" style="width: 100px; height: 100px; align-items: center;">
  <div style="width: 50px; height: 50px;"></div>
</div>

So the oracle is a browser, not a document. A test asserts that Yoga computes the same numbers Chrome computes for the same tree, which is a strong and specific guarantee and also a narrow one.

The cost is in adding a test rather than in trusting one. The fixture is HTML, so you need a browser to generate the expectation, and the generation itself is a Node tool: install yarn classic, run the install step for the test generator's dependencies, then run the gentest script in the yoga directory.

The newest tag is v3.2.1 from December 2024, and the branch has moved since

The release list is v3.1.0 on 2024-06-26, v3.2.0 on 2024-12-03, and v3.2.1 on 2024-12-13. The last push to main was 2026-11-02, nearly two years after the newest tag.

So there are two different answers to what version this is, depending on whether you mean a published release or the state of the source. A project that pins a tag gets 3.2.1. A project that builds from the branch gets nearly two years of commits that no release has captured, and the version number in that build does not reflect them.

This is worth pinning down before you raise a bug, because the number in the reproduction matters. The repository is not archived and the commit date is current, so this is a live branch with a lagging tag rather than a dormant project with an old tag.

For a library that other projects vendor, the same gap shows up in a second place. Yoga is also part of the vcpkg collection of ports, and those ports are maintained by Microsoft and community contributors, with the instruction that if the version is out of date you open an issue or pull request on the vcpkg repository. So a C++ consumer's Yoga can be older than the newest GitHub tag, and the fix for that is filed somewhere else.

The unit test binary takes a configuration name, not a test filter

The build section is short. The main implementation targets C++ 20, with the build logic in CMake, and a wrapper is provided to build the main library and run unit tests. That wrapper is invoked twice in the README, once per configuration:

./unit_tests Debug
./unit_tests Release

So the argument is a build configuration rather than a test name or a filter, and running the whole suite means running the binary twice if you want both configurations. A note follows that the script will use ninja if it is installed, for faster builds, and that this is not required.

The repository root carries a matching Windows wrapper, a batch file. For debugging, Yoga provides a VS Code launch configuration for the unit tests: you add breakpoints and run the configuration named Debug C++ Unit tests with the lldb debugger, or the one named with vsdbg on Windows. Two named configurations, one per platform debugger, rather than a single cross platform entry.

Formatting C++ runs through yarn, prettier and clang-format

The JavaScript side of the repository is not a consumer of Yoga. It is the toolchain that maintains it. The root package is a private package with a version of 0.0.0, and its format script chains four formatters:

yarn format-javascript && yarn format-cpp && yarn format-kotlin && yarn format-python

Each of those is a different tool. JavaScript, TypeScript, Markdown and YAML go through prettier with an explicit file glob. C++ goes through a clang-format driver written as a Node script, invoked with a check flag for the checking variant. Kotlin goes through ktfmt, again behind a Node script. Python has its own driver script. The workspaces are javascript, the test generator, and the website.

Two things follow for a C++ contributor. Formatting is gated on having Node and yarn, and it is four tools rather than one, so a mismatched clang-format or a mismatched ktfmt shows up as a diff that is not about your change. The check variants are separate scripts, and the lint step is a plain eslint over the repository.

The development pins are also older than you would expect for a repository pushed to in November 2026: eslint at 8.30.0, the TypeScript eslint packages at 5.30.5, and typescript at 5.0.4, alongside prettier at 3.9.4. Two transitive packages are pinned through the resolutions field, one of them a nested dependency path.

Fuzzing, benchmarks and three build systems for the bindings sit in one tree

The top level shows how wide the surface is for a library whose implementation is one C++ directory. There is a fuzzing directory and a separate script for building fuzz targets, which is the expected treatment for an engine that computes layout from arbitrary input. There is a benchmark directory, a capture directory, and a scripts directory holding the formatter drivers, with set-version.py and enums.py at the root.

The bindings bring their own build systems. CMake handles the C++ build. A Gradle setup with a wrapper script for both platforms and a properties file, together with a java directory, covers the JVM side. A Package.swift file covers Swift. A javascript workspace covers the npm side, and a website workspace covers the documentation.

Licensing is split too. There is a license file for the library and a separate one for the examples, which is the arrangement you want and the reason to read both. And there are two test directories at the root with different names, which is the sort of thing that makes a first contribution awkward until you find out which one the generator writes to.

The practical summary is that a change to the engine touches one language, and everything around it, formatting, generation, benchmarking, fuzzing and debugging, is coordinated from a JavaScript toolchain that has to work on the platforms the engine does not.

Editorial conclusion

Use Yoga directly if you are writing a C++ application, a terminal UI, or a binding of your own and you need flexbox behaviour that matches what a browser produces, because that is precisely the guarantee the generated tests encode. Do not reach for it as a general purpose layout engine, since the README describes a flexbox engine, and do not assume the branch matches a release. Check four things before you depend on it: which version you are getting, since v3.2.1 is the newest tag and the last push was 2026-11-02; where the version comes from, because a C++ consumer often installs through vcpkg, which a separate community maintains and which can lag; that you have Chrome and yarn classic if you intend to add a test, since the expected results are generated rather than written; and that you have Node and yarn for formatting, since the C++ formatting gate runs through Node scripts. The license is MIT, the implementation targets C++ 20, and the build logic is in CMake.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react/yoga on GitHub
4. README
5. Releases