wagmi: six packages, a generated connector layer, and a README about sponsors

The build script reads top to bottom as a dependency graph

The root package.json is private, typed as a module, and its build entry is the most informative thing in the repository. It runs a connector export generator first, then builds @wagmi/core, @wagmi/cli and create-wagmi as one group, then @wagmi/connectors, and only then the three framework packages: wagmi, @wagmi/solid and @wagmi/vue.

That order is a dependency graph written out in a single line, and it tells you the architecture more directly than any prose would. The core package and the scaffolding CLI compile before the connector layer, and the connectors compile before anything a user installs. A framework wrapper is downstream of all of it.

node scripts/generateConnectorExports.ts && pnpm run --filter @wagmi/core --filter @wagmi/cli --filter create-wagmi build

So the six published packages you are likely to care about, wagmi, @wagmi/vue, @wagmi/solid, @wagmi/core, @wagmi/connectors and @wagmi/cli, come from one workspace built in two waves rather than three independent libraries that happen to share a repository.

Connectors are generated before anything compiles, not hand-maintained

The first thing the build script does is generate connector exports, and the same generator runs again in the prepublish step before the packages are versioned and published. A generated step inside the publish path means the connector surface is derived from some source of truth inside the repository rather than typed out package by package.

The repository layout supports that reading. There is a scripts/ directory at the root next to packages/, playgrounds/ and site/, plus a .changeset/ directory that drives versioning and a .agents/ directory. The root also carries a vitest.config.ts, a biome.json, two tsconfig files and a pnpm workspace definition with a lockfile, so the whole toolchain is committed rather than assembled per contributor.

What you cannot get from the repository is which connectors exist. There is no list in the README, and the generated step means the set can change without a hand-written inventory. Anyone who needs a specific wallet or provider in the plan has to check the generated exports or the published package rather than this source tree.

Three framework packages, three separate version lines

The release history shows the practical consequence of that layout. wagmi itself was published at 3.7.7, @wagmi/vue at 0.5.30 and @wagmi/solid at 0.0.35, and all three landed on 2026-08-27 within seconds of each other. Same commit, same release run, three very different numbers.

The React package is the mature one, sitting on a 3.x line. The Vue package is pre-1.0 and the Solid package is barely off the ground, which means the two wrappers carry API stability guarantees nobody has made yet while the React line carries the deprecation risk that comes with a major version number eventually arriving. If your application is written in Vue or Solid, you are consuming a package whose interface may still change in ways a 3.x number would have signalled.

For a team picking a framework today, that asymmetry is the deciding fact, and it is readable straight off the tags without opening any documentation.

Nine playground dev scripts, none of them mentioned in the README

The scripts reveal a playground directory with one runnable app per integration target: React, Vue, Solid, Solid Start, Nuxt, Next, TanStack Start, the core package on its own, the CLI, and the create-wagmi scaffolder. Each is a separate pnpm filter, and the default dev script simply delegates to the React one.

pnpm --filter vite-react dev

The naming is informative in a small way. The three framework playgrounds are built with Vite, while the meta-framework playgrounds exist for Next, Nuxt and Solid Start, because those need their own build and server behaviour rather than a client-only dev server. Having a TanStack Start app alongside the three established meta-frameworks says the project intends to keep up with that ecosystem rather than only the React one.

None of this appears in the README. If you want to see a working configuration for your stack, the playgrounds are the place, and running the matching dev script is cheaper than reading the docs for a first pass.

Four separate check commands, and one dependency that is deliberately skipped

Quality gates are split by concern rather than bundled. Formatting and linting run through biome with a check script that writes fixes. Types are checked in two modes: one recursive parallel run across packages, plus a tsgo no-emit pass, and a separate TypeScript-specific variant that shells out to tsc per package. Unused exports are caught by running knip after a clean. There is also a type-level benchmark script, bench:types, which runs vitest in a type benchmark mode with a TYPES flag set.

The interesting line is the repository-wide dependency check.

sherif -i viem -p engine-tests

sherif is run with viem ignored and engine-tests as the only package treated separately. Ignoring a dependency in a duplicate-version check means the project has decided not to police viem across its packages, which is a common outcome when a peer or shared dependency is managed by its own release train. It also means a version mismatch there will not be caught by this check. Dependency updates run through taze across the workspace, with a separate CI variant using actions-up.

The cost of that design is visible too: a fix that touches formatting, types, unused exports and dependency policy needs four commands, not one.

The README is a badge wall, a sponsor wall, and a link to the docs

Set the badges and the sponsor logos aside and the README is short. It names the project as reactive primitives for Ethereum apps, points documentation and guides to wagmi.sh, points discussion to GitHub Discussions, points casual conversation to a Discord, asks contributors to read the contributing guide before opening a pull request, and asks for sponsorship.

That is genuinely all of it. There is no install command, no usage example, no API surface and no configuration section anywhere in the file. For a library whose whole purpose is to be added to a dependency list, the absence of an install line is the most surprising gap, and it is worth naming plainly rather than working around.

What the file does carry is a sponsorship request naming the maintainers' GitHub sponsors page, plus a block of sponsor logos from Paradigm, Tempo, Family, Context, Dynamic, Sushi, Stripe, Privy, PancakeSwap, Pimlico, Zora, Syndicate, Relay, Polymarket, Sequence and Web3Auth. A commented-out notice also refers to Gitcoin Grants round 21. The commercial backing is visible even though the usage documentation is not.

A private workspace on a 2026 commit cadence, MIT licensed

Maintenance signals come from the repository rather than the README. The licence is MIT and the default branch is main, with the last push on 2026-10-01. The three most recent release tags are the framework packages mentioned earlier, all published on 2026-08-27, so there was a release run roughly five weeks before that push and the branch has moved since.

The gap between the two dates is the thing to watch. A private workspace at version 0.0.0-style root, with packages versioned through changesets, means the root version carries no information at all; the meaningful versions live in the tags. When a framework package and its underlying core move together in one release run, that is a coordinated changeset release, and coordinating them is the maintainers' job rather than yours.

Nothing in the repository describes a support policy for the 0.x wrappers. There is no statement about how long @wagmi/solid or @wagmi/vue will receive fixes, and no deprecation policy is written down for the 3.x React line. A team betting on Vue or Solid is betting on volunteer attention to a pre-1.0 package with no stated commitment behind it.

Editorial conclusion

wagmi fits a team building an Ethereum or EVM front end in React who wants the connector and account plumbing already solved and does not mind pulling from three npm packages. It does not fit a project that needs its usage documented in the repository, because the README carries badges, community links and a sponsor wall instead. Before adopting it, check three things: which of the React, Vue or Solid packages your framework needs is on a version line that suits you, since those lines do not track each other, and whether the viem exclusion in the dependency check reflects a version coupling you will inherit. Then read wagmi.sh rather than the README for anything beyond installation.

Frequently asked questions

Official sources

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