chakra-react-select reskins react-select with Chakra UI components

A wrapper, and the README says so before anything else

The project describes itself as a Chakra UI themed wrapper for the popular library React Select, and the README spends its first section making that boundary clear. There is a note telling readers that before leaving an issue they should remember this is a wrapper for `react-select` and not a standalone package, that a large percentage of the questions people have end up being about how `react-select` itself works, and that they should read the upstream documentation. That is an unusual thing to lead with, and it is the most useful paragraph in the file. A wrapper inherits the behaviour of the library it wraps, which means it inherits the documentation burden as well. The implementation keeps all the props of the original package, with a few exceptions and a few additions, and the guidance for anyone with a question about basic usage is to check the original docs and swap the package name in your code.

Two lines that track the Chakra major versions

Version compatibility is handled with a branch rather than with a peer dependency, and the README explains the split. This version of Chakra React Select is updated for Chakra UI v3, which works exclusively with React version 18 or above. Chakra React Select v5, which is compatible with Chakra UI v2, is maintained for the foreseeable future, and anyone still on Chakra UI v2 is pointed at the v5 documentation. The published releases follow the same pattern, with 6.1.3 and 5.1.1 both published in May 2026 and 5.1.0 earlier in the year. The practical consequence is that an application on Chakra v2 does not get the v6 improvements, and an application on v3 has no fallback line, since the v5 branch targets the older Chakra. The upgrade path, in other words, is a coordinated move of both your Chakra version and this package.

Installing Chakra, Emotion, and then the package

The package has a real dependency, and the README insists you set it up first. To use it you need `@chakra-ui/react@3` configured as in the Chakra installation guide, and then the wrapper itself from npm:

npm i @chakra-ui/react @emotion/react
# ...or...
yarn add @chakra-ui/react @emotion/react

npm i chakra-react-select
# ...or...
yarn add chakra-react-select

Beyond the Chakra UI setup the README already requires, there is no separate stylesheet to import and no package-specific theme entry to add, which is the practical appeal of the wrapper. The manifest explains why that is possible. The package declares a single runtime dependency, `react-select` at `^5.10.2`, is marked as having no side effects, and ships only its `dist` directory, with a CommonJS build at `dist/index.js`, an ES module at `dist/index.mjs`, and separate type declarations for each, so the types resolve correctly whether a consumer imports or requires.

Four exports and a passthrough for everything else

The package exposes four components, the base select, the async select, the creatable select and the async creatable select, importable as named exports or destructured from a require call:

import {
  AsyncCreatableSelect,
  AsyncSelect,
  CreatableSelect,
  Select,
} from "chakra-react-select";

Beyond those four, all exports and types from the original `react-select` package are re-exported, so anything you needed from the upstream library, including its types, is available from this package too. The only exception is the root `Select` components, which are replaced by the Chakra versions. The reason this works is that the wrapper does not reimplement the combobox. It renders react-select's behaviour with Chakra components underneath, so the accessibility and keyboard handling you get are the ones react-select already provides, along with the `combobox`, `listbox`, `menu` and `dropdown` roles named in the package keywords.

The extra props that make it look like the rest of the app

The additions are the point of the wrapper, and the README documents them one by one. `size` accepts `sm`, `md` or `lg` and mirrors the sizes available on the Chakra `<Input />` component, with `xs` excluded because it is too small to work, and it also accepts a responsive style array or object so the control can change size at your theme's breakpoints, defaulting to `md`. `tagColorPalette` and `tagVariant` control the multi-select tags, with `tagVariant` taking `subtle`, `solid` or `outline` and defaulting to `subtle`. `invalid` and `readOnly` are passed through to the input, `focusRingColor` sets the focus ring colour, `variant` chooses `outline` or `subtle` and defaults to `outline`, and `selectedOptionStyle` and `selectedOptionColorPalette` control how the chosen option is highlighted, with the palette defaulting to blue. These are the props that make a select look like it came from the same design system as the rest of the form.

Styling hooks, and the caveats that come with them

There are three ways to restyle it. `chakraStyles` lets you override the styles of the underlying Chakra parts, and the README documents the caveats of that approach along with examples. Theme styles apply the styles from your Chakra theme. `className` is the escape hatch for passing your own class names. The React Select props remain the base, and the wrapper adds to them rather than replacing them, so the styling surface is genuinely wide. That width is also the risk. A `chakraStyles` override that reaches into react-select's internal class names will break when react-select changes, and the README's caveat section is where it says so. A team that wants a stable look should reach for the theme and the extra props first, and keep deep overrides to the minimum.

The toolchain behind a small package

The repository shows a modern release process. The build is `tsup --clean`, the linter is `oxlint` with its own config, the formatter is `oxfmt`, the type check is `tsc`, and the tests run under Vitest. Publishing is checked rather than assumed, with `publint` for the package and `attw --pack .` for the export map, which is what catches the common mistake of shipping types that do not match the module format. Commit hooks are set up with Husky and lint-staged, the demo application is a separate workspace package built with Vite, and there is a `codemod/` directory for helping people move between versions. The licence is MIT, in a `LICENSE.md` file, with a `SECURITY.md` alongside it. The releases are regular, and the last push to the repository was on 2026-06-30.

Editorial conclusion

Adopt chakra-react-select when your application is already built on Chakra UI and react-select is the behaviour you want, since the wrapper keeps react-select's props and API and only replaces the rendering, and the v6 line adds Chakra specific props such as `size`, `tagColorPalette` and `variant`. Do not adopt it to learn combobox behaviour, because the README is explicit that it is a wrapper and that most questions about it are really questions about react-select. Verify first which Chakra major version you are on, since v6 requires Chakra UI v3 and React 18 or above while the v5 branch covers Chakra UI v2, and note that the last push was on 2026-06-30 with the newest published version at 6.1.3.

Frequently asked questions

Official sources

1. csandman/chakra-react-select on GitHub
2. License: MIT
3. Project website
4. README
5. Releases