Chakra UI's install is two packages, and its postbuild step generates the tokens

The install command adds two packages and the second one is Emotion

The installation section is the most useful part of this README, and it is short. To use Chakra UI components you install the @chakra-ui/react package and its peer dependencies, and all four package manager lines add the same pair.

# with Yarn
$ yarn add @chakra-ui/react @emotion/react

# with npm
$ npm i @chakra-ui/react @emotion/react

# with pnpm
$ pnpm add @chakra-ui/react @emotion/react

# with Bun
$ bun add @chakra-ui/react @emotion/react

That second package is the styling engine, and it is not bundled. Nothing in the install output tells you it was required, so a project that copies only @chakra-ui/react finds out at runtime, not at install time. The four commands are otherwise identical, which means the choice of package manager has no effect on what lands in your dependency tree.

This is the axis on which the library differs from the copy-in approach. A system where you paste component source into your own repository has no runtime dependency and no version to keep in step. Chakra UI is the other arrangement: a dependency you upgrade, plus a peer dependency you own.

postbuild runs a typegen pass over packages/react/src/preset.ts

Compiling this repository is not only a TypeScript build, and the root package.json is where that shows.

"build": "pnpm --filter=./packages/* build",
"build:fast": "pnpm --filter=./packages/* build:fast",
"dev": "pnpm --recursive --parallel --filter=./packages/* dev",
"postbuild": "pnpm build:tokens",
"typedocs": "pnpm www generate:types",
"typecheck": "tsgo --noEmit",
"test": "vitest",

The postbuild hook runs build:tokens, which is chakra typegen pointed at packages/react/src/preset.ts. That file is the source the design tokens are generated from, and a developer variant of the same command sets LOCAL=1 through cross-env. The typecheck script is tsgo rather than tsc, and the test runner is vitest with a separate bench script that runs benchmarks.

For a user this is invisible, and for anyone building from source it is the part to know: compiling the packages is not enough, because a code generation pass runs afterwards over a preset file inside packages/react.

react, panda-preset and codemod all moved to 3.37.0 on the same day

The three most recent releases are @chakra-ui/react 3.37.0, @chakra-ui/panda-preset 3.37.0 and @chakra-ui/codemod 3.37.0, all published on 2026-08-28. They are separate packages on npm that share one version number and one publication window, and the release script is changeset publish, preceded by changeset version.

Lockstep versioning has a cost worth naming. Upgrading @chakra-ui/react without the matching @chakra-ui/panda-preset leaves you on a preset from a different generation, and the token output is generated from the preset rather than from the component package. The presence of a codemod package at the same version is the maintainers' answer to that class of problem: a major change arrives with a script to apply it.

There is also a prerelease channel. The scripts next:enter and next:exit run changeset pre enter next and changeset pre exit next, so a canary build exists alongside the stable one. The last push to main was on 2026-09-24, which is a month after those tags and means the branch is ahead of every published version.

v0, v1, v2 and the current docs are all still being served

Four documentation generations are listed at the top of the README, each on its own subdomain: the current version at chakra-ui.com, then v2.chakra-ui.com, v1.chakra-ui.com and v0.chakra-ui.com. Nothing in the repository retires them.

That is a real problem for anyone arriving through a search result, a tutorial written two years ago, or a language model. A snippet copied from v2 is still online and still correct for v2, and the difference between a v2 and a v3 setup is large enough that copying it will not fail loudly. The README's own usage line makes the point indirectly: rather than show a component, it sends you to a get-started installation page on the website, which means the repository file cannot tell you which generation any given example belongs to.

The practical habit is to check the subdomain in the address bar before copying anything, and to treat the current site as the only source for a 3.x install.

scripts/symlink.ts swaps installed packages for local links

Two scripts in the root package.json exist purely for the contributor workflow. local:sync runs tsx scripts/symlink.ts, and local:revert runs the same script with --revert. Between them they point a checkout at the packages in this repository instead of the ones on npm.

The rest of the tree explains what they are syncing. There is a pnpm-workspace.yaml and a pnpm-lock.yaml, a packages/ directory holding the published code, an apps/ directory with separate entries for the documentation site and for an MCP server, plus sandbox/, scripts/, media/ and skills/. Building is a filtered workspace command, pnpm --filter=./packages/* build, and the dev script runs the same filter recursively in parallel.

The consequence is that a fork's local build is not the same artifact a consumer installs. Anything you see running in a development checkout may be resolving through a symlink to a package version that was never published, so a bug reproduced locally and a bug reported from npm are not guaranteed to be the same code.

An MCP app, a skills directory, and a Storybook on port 6006

Some of the top level entries are not about components at all. There is a skills/ directory, a .claude/ directory and a CLAUDE.md, and the package.json exposes an mcp script that filters to ./apps/mcp. Agent-facing material is part of the repository rather than a separate project, which tells you how the maintainers expect the library to be used in 2026.

The rest is conventional and worth knowing before you file anything. Components are developed against Storybook, with storybook dev on port 6006 and a build:storybook script that runs the fast build first. renovate.json handles dependency updates, .commitlintrc plus .husky/ and .lintstagedrc enforce the commit format, .nvmrc pins the Node version, and .changeset/ and .changelog/ hold the release bookkeeping. Tests run through vitest with a vitest.setup.ts at the root, and linting uses a flat eslint.config.mjs with a .prettierrc for formatting.

For a consumer none of this matters. For a contributor it is the difference between a two-file change and a change that has to pass typecheck, lint, format and commit rules.

MIT under a single named author, with funding through Open Collective

The licence line is one sentence: MIT, copyright Segun Adebayo, and the same person is the author field in the root package.json. A permissive licence with one named copyright holder is straightforward to adopt and leaves a project with a single point of legal continuity, which is worth weighing for anything long lived.

Money comes through Open Collective, split between organisation sponsors whose logos appear in the README and individual donations, with the note that donating $5 or more supports ongoing development. The same section carries testimonials and an awards table naming a Thoughtworks Technology Radar entry called Solution Worth Pursuing and an Open Source Awards entry for the most impactful contribution to the community. Those are the project's own claims about reception, useful as history and not as evidence about how the library behaves in your codebase.

There is a SECURITY.md and a CODE_OF_CONDUCT.md in the tree, and the contribution guide lives on the website rather than in CONTRIBUTING.md, which is the file the README points you at.

Editorial conclusion

Chakra UI fits a React team that wants accessible components plus a token system generated from a preset file, and it does not fit a project that wants no runtime dependencies, because @emotion/react has to be installed and kept in step beside @chakra-ui/react. Verify first which documentation generation you are reading, since v0, v1, v2 and current are all served at the same time, and check that @chakra-ui/react, @chakra-ui/panda-preset and @chakra-ui/codemod sit on the same version before you start a migration.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes