RainbowKit's root manifest is a private 0.0.0 workspace, not the package you install

The root manifest is private at 0.0.0 and four packages do the publishing

The package manifest at the repository root is not the package most people install. It reads name rainbowkit, private true, version 0.0.0 and type module. A private manifest with a placeholder version is the shape of a workspace root rather than a published library.

The names that get published are scoped and they are three, all released on the same day in May 2026: the main library at 2.2.11, a sign-in-with-ethereum helper for Next.js auth at 0.6.0, and a button component at 0.2.28. A fourth package, the scaffolding CLI, appears in the development scripts by its own scoped name. So the same repository contains a library at version 2, an auth integration at 0.6, a button at 0.2 and a CLI, and the version numbers do not move together.

The mechanics are a pnpm workspace with a workspace file and a lock file, plus a changesets directory, a changeset script and a release script. Version bumps are therefore described as changesets rather than edited by hand, which is why three packages can ship on one day with unrelated version numbers.

One clean script deletes every untracked file except two

There are two clean scripts and they behave very differently. The plain one is a fixed list: it removes the dist directory of the library, of the auth integration, of the button and of the CLI, plus the library's node_modules, and then reinstalls.

The other one is a single destructive line. clean:untracked runs git clean with the force flag, the flag that removes ignored files as well, and the flag that removes directories, excluding exactly two names, .env.local and .env, and then reinstalls dependencies.

Read together, those flags mean every untracked file in the working tree is deleted, including anything a .gitignore already hides, and the only things spared are the two environment files. A scratch file you left next to an example, a build output from another tool, a local patch, and a file a tool wrote into an ignored directory all go, without a prompt.

The two exclusions are the tell. They exist because the environment files are exactly what a developer would lose, which tells you what the script's author expected to be at risk and what everything else was considered disposable.

The wallet registry is fetched by a script, not maintained by hand

The library's headline feature is out-of-the-box wallet management, and the repository has a script whose only job is to fetch the wallet registry: fetch:wallets runs node on a file called walletRegistry.js in the scripts directory.

That is the mechanism behind the modal. The list of wallets a user picks from is data pulled from somewhere and written into the package, not a switch statement typed into a component. So there are two questions a consumer inherits. Where the registry comes from at build time, and how fresh it is, because a wallet list that is fetched occasionally is a wallet list that lags new wallets, new chains and renamed entries.

The rest of the page describes the library in three lines: wallet connection that works out of the box, easy customisation, and being built on top of wagmi and viem. Those two foundations are named as links rather than described, which tells you where the chain and transport layers come from and leaves the modal, the account display and the wallet list as this repository's own contribution.

Three gates sit behind the lint script

The lint script is a chain of three checks rather than one. It runs biome lint over the repository, then a format check, then a recursive typecheck across the workspace.

The format check is itself a script, and it is not a separate formatter invocation: it runs biome check, so the same tool that lints also verifies formatting. The configuration file for it is biome.json at the root. The typecheck stage is the expensive one, since it recurses into every package in the workspace rather than stopping at the library.

The commit side is wired too. A prepare script runs husky, the hook directory is at the root, and commitlint has its own config file, so commit messages are validated by a git hook installed on install. The result is a repository where a change has to pass linting, formatting, type checking across packages and a commit message convention before it lands, with the type checking done per package rather than once.

Two dev servers share one terminal

The development scripts show how a library and its examples are run at the same time. The dev script walks the workspace recursively and in parallel, filtered to the rainbow scoped packages and to anything named example.

The narrower variants use the shell's background operator. dev:example runs the library's dev task and the example's dev task joined by an ampersand, and dev:site does the same with the site package instead. dev:cli runs only the CLI package, and there is a separate script for one named template.

Joining two commands with an ampersand puts both in the background of that shell and returns immediately, so the two dev servers write to the same terminal and neither is waited on. That is why the parallel flag appears in the recursive script but not in these: the recursive form asks the package manager to coordinate, the ampersand form asks the shell to.

The build script is recursive and parallel too, with one exclusion: the next app template is filtered out of the build. The start script is not a production start at all, it is an alias for dev.

The examples folder holds three examples the list does not mention

The page lists ten examples: Create React App, Next.js, Next.js App Router, a custom button, minting an NFT, two sign-in-with-ethereum variants, Remix, Vite and React Router. Six of those also have CodeSandbox links, which is a subset, since the sandbox links stop at Remix and Vite and do not include the custom button or the minting example.

The examples directory in the repository holds thirteen. Three of them are not on the list: one for the App Router with internationalisation, one built around the Rainbow button, and one built around a wallet button. So the list covers the frameworks you would choose between, and the folder covers the variations that were added later.

Running one is three commands rather than one. Install dependencies at the root with pnpm install, change into the example directory, for example examples/with-next, and run its dev script. Nothing in that sequence installs browser extensions or creates wallet configuration, so the amount of setup a first run needs is not visible from the page.

Two of the three scaffold commands are pinned to the latest tag

The quick start offers three ways to scaffold, one per package manager:

npm init @rainbow-me/rainbowkit@latest
# or
pnpm create @rainbow-me/rainbowkit@latest
# or
yarn create @rainbow-me/rainbowkit

The first two end with the latest tag and the third does not. Whether that is deliberate or an oversight, the effect is that two of the three commands resolve to the newest published version by name and one resolves to whatever the package manager's default tag points at.

What is scaffolded is stated in one sentence: a RainbowKit, wagmi and Next.js application. So the scaffolding tool makes a specific stack choice, and picking Vite or Remix means starting from the repository examples instead.

The rest of the page is links. Full documentation lives on rainbowkit.com, the title row carries a link to a DeepWiki entry, contribution goes through the guidelines file, and the licence is MIT with a copyright line reading 2022-present Rainbow. The repository itself holds the documentation site, a translation configuration file, agent instruction files, a devcontainer definition and an nvmrc, none of which the page mentions.

Editorial conclusion

RainbowKit fits a React application that wants a wallet connection modal with the wallet list already assembled, and it inherits its chain abstraction from wagmi and viem rather than inventing one. Three things to check before you commit to it. Read the documentation site, because the repository page is a quick start and a list of examples, not a reference. Expect to run the fetch script or accept the wallet registry as generated data rather than hand-maintained. And look at the clean scripts before you run them in a working tree, since one of them removes every untracked and ignored file except two environment files.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. rainbow-me/rainbowkit on GitHub
4. README
5. Releases