# rnx-kit: Microsoft's React Native Tooling, and Where align-deps Fits

> rnx-kit is a monorepo of React Native developer tools from Microsoft, best known for align-deps, a dependency version manager. It is most useful to teams running large React Native apps, and least useful to small projects that have not yet hit version drift.

**microsoft/rnx-kit** — Modern, scalable tools. Exceptional developer experience.

- Repository: https://github.com/microsoft/rnx-kit
- Website: https://microsoft.github.io/rnx-kit/
- Stars: 1,736 · Forks: 119
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-rnx-kit

## The problem rnx-kit targets: version drift in large React Native projects

The README describes rnx-kit as a collection of tools created by Microsoft engineers to fill gaps in the React Native ecosystem. The gap it names first is dependency management: keeping consistent dependency versions across large projects with align-deps. In a monorepo where several packages each declare their own React Native, React, or Metro version, those declarations drift. One package upgrades, another does not, and the mismatch surfaces later as a runtime error or a bundling failure that is hard to trace back to a version range. align-deps exists to make that class of problem visible and fixable.

The audience follows from that. Microsoft states these tools are used daily to ship React Native apps at scale across the company, and the repository layout reflects it: a Yarn workspaces monorepo with packages and incubator directories, Nx for task running, and Changesets for versioning. That is infrastructure for a large codebase, not a starter template. If you have one small app with a single package.json, align-deps has nothing to align. The tools that do not depend on scale, such as the Babel preset for Metro, are usable on their own.

## How the monorepo is organised and how the tools ship

Every tool lives in its own package under packages, with experimental work under incubator. The root package.json is private and declares workspaces across incubator/*, incubator/@react-native-webapis/*, packages/*, and scripts. Each package is published independently to npm under the @rnx-kit scope, which the recent releases confirm: @rnx-kit/types-kit-config, @rnx-kit/types-bundle-config, and @rnx-kit/tools-react-native each carry their own version and their own release entry.

The practical consequence is that you do not adopt rnx-kit as one thing. You install the specific packages you need, or you adopt the all-in-one CLI that the documentation's introduction guide describes. Versioning is handled with Changesets: the root scripts include change (changeset add), change:check (changeset status), version:changesets (changeset version plus a lockfile update), and publish:changesets. Builds and tests run through Nx targets; build:ci runs only affected projects. That means an individual package's version number tells you nothing about the state of the others, so pinning is per package. The MIT licence applies at the repository root, and each published package carries its own licence field.

## Installing rnx-kit and running align-deps for the first time

The README does not print install commands. It points to two documents instead: the Introduction guide, which covers adding the all-in-one CLI, and the Getting started guide, which is the easier introduction to the dependency management tool. If you want a single tool rather than the CLI, the README says to refer to that tool's own README, all of which are listed in the Tools section of the documentation site.

Because the repository is a Yarn workspaces project (there is a .yarnrc.yml, a .yarn directory, and a yarn.lock at the root), the published packages are consumed from npm like any other dependency, and the package name is the one you want. The repository's own root scripts are the entry points if you are working inside a clone rather than consuming published packages. These run the whole workspace:

```bash
yarn build
yarn test
```

and this runs only what your changes affect:

```bash
yarn build:ci
```

There is also a script that builds and runs align-deps from the workspace itself:

```bash
yarn rnx-align-deps
```

For a first real use of align-deps, follow the Getting started guide rather than guessing at flags: the README does not list align-deps command-line options, and the guide is where the project documents the workflow. Expect the output to be a report of dependencies whose declared versions do not match the versions align-deps expects for your React Native release, followed by a command to apply the corrections.

## Metro enhancements and the Microsoft Babel preset

The bundling tools take a different approach from align-deps. metro-serializer lets you enhance Metro rather than replace it, and the README lists the features it can add: TypeScript validation inside Metro, tree shaking, and detection of duplicate and cyclic dependencies. Because it plugs into Metro's serializer stage, it composes with an existing metro.config.js instead of requiring a different bundler.

There is also a Babel preset for Metro that the README describes as opinionated for Microsoft usage. That phrasing is honest and worth taking literally: the defaults encode one company's conventions. If your project already has a settled Babel configuration, adopting this preset means adopting those conventions, and the README does not enumerate what they are. Read the preset's own README before swapping it in.

The native build tool is the one to treat with caution. The README labels it experimental and describes it as building Android and iOS apps in the cloud so you can avoid installing heavy native toolchains. Experimental status in a Microsoft repository means the interface can change between releases, so it is a poor fit for a release pipeline you cannot afford to repair on short notice.

## Where rnx-kit is the wrong choice

The clearest limitation is scope. align-deps solves a problem that only appears once a project has multiple packages or a long-lived dependency graph. A single-app project with one package.json gets configuration overhead and no benefit. The same applies to the all-in-one CLI: the README frames it as getting most of the tools out of the box, which is only an advantage if you want most of the tools.

The second limitation is documentation depth in this repository. The README is a signpost, not a manual. It names the tools and links out, and the root README does not document align-deps flags, the Babel preset's contents, or the metro-serializer configuration surface. The repository does carry an AGENTS.md, a CLAUDE.md, a ROADMAP.md, and a TASKS.md, which suggests internal planning happens in the open, but none of those is a substitute for the per-tool READMEs. If you need a tool whose behaviour is fully specified before you install it, check the individual package README first.

The third is version coupling. Because packages release independently, an upgrade to @rnx-kit/tools-react-native and an upgrade to an align-deps package are separate decisions with separate release notes. There is no single rnx-kit version to pin.

## How rnx-kit differs from React Native Community CLI and Expo

The React Native Community CLI is the default project scaffolding and command surface that ships with React Native itself. It creates a project and runs it; it does not manage dependency version consistency across a monorepo. rnx-kit assumes you already have a project and adds the layer above it. The two are not competitors in the sense of replacing one another: rnx-kit's build tool is an alternative to local native toolchains, and its bundling tools extend Metro, which the Community CLI also uses.

Expo takes the opposite approach to the same underlying problem. It provides a curated set of compatible package versions through its own SDK, so consistency is enforced by staying inside the SDK. rnx-kit's align-deps enforces consistency by checking your existing declarations against expectations for a given React Native version, which means it works with a dependency graph you already have rather than one chosen for you. If you have already committed to Expo's SDK, align-deps addresses a problem Expo largely removes. If you have a bare React Native monorepo with your own dependency choices, align-deps is aimed at you.

## Maintenance, releases and what an upgrade costs

The repository is not archived, and its last push was on 2026-09-10. Releases are frequent and granular: three packages published on 2026-09-01, each with its own patch version. That pattern means upgrade cost is per package, not per release train. You can take a patch to @rnx-kit/types-kit-config without touching any other tool.

The cost sits in the configuration you write. align-deps needs to know which React Native version your project targets before it can judge your dependencies, so an upgrade to React Native is the event that forces an align-deps pass. The metro-serializer plugins you enable are code you maintain inside your Metro config. The Babel preset is a set of defaults you either accept or override.

On licensing: the repository is MIT, and the root package.json declares MIT with Microsoft Open Source as author. Each published package is a separate artifact, and the repository carries a SECURITY.md and a CODE_OF_CONDUCT.md alongside the LICENSE file. Check the licence field of each package you add rather than assuming the root licence covers all of them, and note that the README points to a third-party notices topic, which matters if your organisation reviews dependency licences.

## Conclusion

Adopt rnx-kit if you maintain a React Native app or monorepo where dependency versions have started to drift between packages, or if you want the Microsoft-tailored Babel preset for Metro. Skip it if you are starting a single small app; the all-in-one CLI and align-deps assume enough dependency surface to be worth configuring. Before committing, verify which packages are still experimental (the README labels the native build tool as experimental), check the licence file for each package you pull in, and read the align-deps README to confirm it supports your React Native version before you change any package.json.

## FAQ

### What is rnx-kit?

rnx-kit is a collection of React Native developer tools created by Microsoft engineers, published as separate packages under the @rnx-kit npm scope. The README groups them into dependency management, experimental native builds, bundling enhancements for Metro, and a Microsoft-tailored Babel preset.

### How do I install rnx-kit?

The README does not print install commands. It directs you to the Introduction guide for the all-in-one CLI or the Getting started guide for align-deps, and says to read a tool's own README if you only want that tool.

### What does align-deps do?

The README describes align-deps as the tool for ensuring consistent dependency versions across large projects. It is the dependency management entry in the tools list, and the Getting started guide is the project's introduction to it.

### Is rnx-kit the same as React Native itself?

No. rnx-kit is a separate set of tools that the README describes as filling gaps in the React Native ecosystem; it is not the React Native framework. It is maintained by Microsoft engineers and published under the MIT licence.

## Sources

- [License: MIT](https://github.com/microsoft/rnx-kit/blob/main/LICENSE)
- [microsoft/rnx-kit on GitHub](https://github.com/microsoft/rnx-kit)
- [Project website](https://microsoft.github.io/rnx-kit/)
- [README](https://github.com/microsoft/rnx-kit/blob/main/README.md)
- [Releases](https://github.com/microsoft/rnx-kit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-rnx-kit
