React Native Directory: a JSON file that powers a searchable package index

The JSON file is the product

React Native Directory is a website where you can browse through all the libraries that are compatible with React Native, and the website is the visible part of something much simpler.

The data lives in a single file, `react-native-libraries.json`, with a matching `react-native-libraries.schema.json`. The contribution instructions are built around that file. To update a library, find its entry, update the data using the library fields description as a guide, and submit a PR. To add a library, add it at the end of the file, and the reason for that is stated: the order in the file is used for the Recently added sort option.

That detail is the kind of thing that reveals how a static file is made to work. A JSON array has no inherent order that a database would preserve, so the file's physical order becomes meaningful, and appending becomes the way to make something new appear at the top of that sort.

The entry format is strict, and the template is published in the documentation:

{
  "githubUrl": "<GITHUB REPOSITORY URL>",
  "npmPkg": "<OPTIONAL NPM PACKAGE NAME>",
  "examples": [
    "<THE URL TO REPO>",
    "<THE URL TO A SNACK>"
  ],
  "images": ["<PUBLIC URL TO RELATED IMAGE>"],
  "ios": false,
  "android": false,
  "web": false,
  "windows": false,
  "macos": false,
  "tvos": false,
  "visionos": false,
  "expoGo": false,
  "fireos": false,
  "harmony": false,
  "horizon": false,
  "vegaos": false,
  "newArchitecture": false,
  "configPlugin": false,
  "unmaintained": false,
  "dev": false
}

The instruction above it is the one to follow: follow format, fields order and indentation as seen below, skip any of the `false` values and do not fill optional fields unless it's necessary.

So the entry is a set of booleans, mostly false, and the booleans are the value. A directory of React Native packages where every entry says it works with React Native is not a directory, it is a list, and the flags are what turn the list into a filter.

The licence is MIT, the site is at reactnative.directory, and the site is hosted on Vercel, which is the hosting arrangement the badge advertises.

Platform flags, and the rule for out-of-tree platforms

The platform fields are the substance of the directory, and they are grouped by how much evidence is needed to claim them.

The three mainstream React Native platforms are `android`, `ios` and `web`. The web one is defined as can be used with `react-native-web`, which is a specific library rather than a generic idea of the web, and the other two are works on an Android device and works on an iOS device.

Then there is the out-of-tree group, and this group has a stricter rule attached. Adding out-of-tree platforms support requires an example or link to the app which uses the library on the given platform.

That requirement is the interesting part, because it applies to `windows` with react-native-windows, `macos` with react-native-macos, `tvos` with react-native-tvos, and `visionos` with react-native-visionos. These platforms are not part of core React Native, they are separate renderers maintained by other people, so a library that works on iOS does not automatically work on Windows. Requiring a link to a working app is what stops the directory from filling up with optimistic claims.

The compatibility group works the same way but in a different direction. `expoGo` means the library works with Expo Go, which is an open-source sandbox app, without using dev clients or prebuild, and there is a tip attached: any library can be used with Expo if you use dev clients or prebuild. So the flag is specifically about the Expo Go sandbox, and the tip is the workaround for the libraries that cannot run in it.

Then `fireos` for Amazon Fire OS, `horizon` for Meta Horizon OS, and two that can be more than a boolean. `harmony` is a boolean or a string containing an npm package name, if a separate or additional package is required for full support on HarmonyOS. `vegaos` is a boolean or a string, for Amazon's Vega OS, with the same reason.

That string variant is a nice piece of design. Sometimes a library supports a platform only through an additional package, and a plain false would be wrong and a plain true would overstate what the library itself does. A string names the package that makes it work, and a person reading the directory learns something they could not learn from a checkbox.

The tags that change how an entry is read

Four fields are about the health and shape of the package rather than where it runs, and they change how the entry should be interpreted.

`unmaintained` signifies that a library is no longer maintained, and there is an `alternatives` field for pointing at replacement libraries if needed. This is the most consequential flag in the file, because the default assumption when you see a package in a directory is that someone is looking after it, and this flag says when that is not true.

`dev` signifies that a library is a development tool or is only a part of a development process. A build tool and a runtime dependency are not the same kind of thing to depend on, and the flag separates them.

`configPlugin` is a boolean or a string containing a URL to a third-party config plugin, and it indicates if the library includes an Expo config plugin. The documentation adds that if the plugin is provided by a third party, supply the URL as a string, and that the field is optional and will be detected automatically if omitted. So the field is a shortcut that is usually filled in for you, and the string form is for the case where the plugin lives somewhere else.

`newArchitecture` is a boolean or the string `new-arch-only`, signifying that a library supports both, or not, the New Architecture and the Old Architecture, or only the New Architecture. And the important part: skipping the field will result in an untested status, unless automatic support detection returned a result.

That last sentence is the whole point of the flag existing. React Native's New Architecture is a rewrite of the bridge and the renderer, and a large number of packages were not written for it, so a package that says nothing is genuinely ambiguous, and the directory would rather say untested than guess.

The `npmPkg` field has a similar logic. By default the GitHub repository name is used, and the instruction is to fill it only when the GitHub repository name is different from the name of the package published to npm, or the package is a part of a monorepo. And `githubUrl` is required, with the warning that the package also needs to be published to the NPM registry, because the npm registry is one of the directory's data sources.

That last requirement explains the monorepo note too. If your package is within a monorepo, then the name, description, homepage and topics are extracted from the `package.json` in the package subdirectory, but the GitHub stats will be based on the monorepo, because there isn't really another option. The entry is right, and one number in it is a compromise.

The pipeline that scores, fetches and validates the data

The package manifest is where the machinery behind the site becomes visible, and the script names describe the whole pipeline.

The data side has four commands. `data:fetch` runs `bun scripts/fetch-latest-blobs`. `data:update` runs `bun scripts/build-and-score-data`, and `data:update-missing` runs the same with a `--missing-only` flag. `data:test` runs `bun scripts/validate-libraries`, and `data:validate` runs ajv to validate the data against the schema with `--verbose --allowUnionTypes`.

The ajv call is the direct line to the schema, and the `--allowUnionTypes` flag tells you the schema uses union types, which is what allows `harmony` and `vegaos` to be a boolean or a string, and `newArchitecture` to be a boolean or a specific string.

Then the library hygiene commands. `libraries:cleanup` runs a cleanup script and then formats the JSON with oxfmt, which is how the file stays consistently formatted after many small edits. `libraries:recalculate` recalculates the scores. `libraries:check` runs `bun scripts/check-resources`, which is the check for the example and image URLs.

And the build itself is a sequence: `build` runs `bun data:fetch && bun llms:generate && next build --webpack`, `build:with-data` runs the full `data:update` first, and `build:quick` runs the missing-only variant, which is the one to use when you are not waiting for a full data refresh.

The `llms:generate` step in the middle of the build is a recent addition and worth noting. It runs `bun scripts/generate-llms`, and it is there because the directory is a structured dataset that an assistant can consume, so it is generated in a form for that rather than only as a website.

The CI commands are `ci:cleanup-blobs` and `ci:validate`, the latter running `bun scripts/validate-new-entries`, which is the check that a new entry conforms. The `readme` script runs `bun scripts/readme-existence.ts`, which checks that a repository mentioned actually has a readme.

The `data:update-missing` and `build:quick` pairing is the useful detail. A full data refresh fetches every repository's latest state and rescores everything, which is slow, and the missing-only variant fills in just the gaps, which is what you want in a normal build.

The site itself is a Next.js app, since the scripts use `next dev --webpack` and `next build --webpack`, and the front end is in `components/`, `scenes/`, `context/`, `hooks/` and `common/`, with Tailwind and PostCSS, Radix UI primitives for popovers, tooltips and hover cards, visx for the charts, Sentry for error reporting, and a `patches/` directory.

Where the directory falls short, and the CLI alternative

There are limits to what a directory of this kind can do, and they are worth stating because the flags create an impression of completeness that the underlying process does not support.

The first is that the data is as good as the last pull request. Every platform flag is an assertion made by whoever submitted the entry, and the out-of-tree platform rule asks for a link to a working app, but a link can go stale and the flag stays true. A package that worked on react-native-windows in 2024 and stopped working is still listed as working, because nothing re-checks it.

The second is the `unmaintained` flag, which is self reported. A package can go unmaintained without anyone flagging it, and the failure mode is the dangerous one, since a package that looks alive in the directory is the package someone picks.

The third is that a directory is a snapshot. The project documentation for adding a library says to use the template and follow the format, fields order and indentation, and there is no mention of a mechanism for removals or for flagging something that has stopped working. The `alternatives` field exists for the unmaintained case, which is a partial answer, but the general case of a broken entry is not covered.

There is also a tension in the `newArchitecture` detection, which the documentation says will be used unless automatic support detection returned a result. Detection is a heuristic, and a heuristic that is right most of the time is what a directory can offer and not more.

The alternative to the web directory is the command line, and the project points at one. You can use the React Native Directory CLI to submit a library directly from the terminal, running `bunx rn-directory submit` from the package root folder, and the CLI lives at the Simek/rn-directory repository. For a maintainer adding their own package, that is a faster path than opening a pull request against a large JSON file.

The other alternative is the VS Code extension, which the project recommends for looking up a library from the editor, at the react-native-community/vscode-react-native-directory repository.

On maintenance, the repository is not archived and the last push was on 2026-10-18, so the directory is actively kept. The licence is MIT, and the site runs on Vercel.

Editorial conclusion

React Native Directory fits a developer picking a React Native dependency, because the per-platform and per-architecture flags tell you whether a package actually runs on Windows, macOS, tvOS, VisionOS, Fire OS or HarmonyOS rather than just claiming React Native support, and the new architecture and Expo Go flags catch the two most common disappointments. Skip it if you only need one well known package, since the search is faster than the data is deep. Before you add your own library, follow the template exactly, because the field order and indentation are checked, and note that the package must be published to npm, since npm data is one of the directory's inputs. The last push was on 2026-10-18.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. react-native-community/directory on GitHub
5. README