Flowbite React: two CLIs, twenty-four framework guides and a pre-release banner

Tailwind utility classes in React state, minus part of the vanilla set

Flowbite React presents itself as an open source collection of UI components built with React and Tailwind CSS utility classes, offered as a starting point for interfaces rather than a finished design system. The primary language in the repository is TypeScript, and the topic tags name `a11y`, component-library, reactjs, storybook and tailwindcss. What changes for a React team is where behaviour lives. In plain Flowbite the same visual language ships as markup plus a JavaScript layer bound to data attributes. Here that behaviour becomes props and state inside your own tree, so an open menu or a picked date is a value in your component rather than an element some page-level script has to find.

One gap is stated plainly in the README: some components from the vanilla Flowbite library are not yet available in Flowbite React. A team migrating an existing Flowbite page can hit that on day one, and no repository file enumerates which pieces are missing.

The `a11y` topic tag is a label the repository applies to itself. It carries no conformance statement, and the README makes no claim about keyboard order or screen reader output, so those expectations have to be checked in the docs at flowbite-react.com.

Two CLI entry points decide how the library reaches your project

Setup splits across two commands that ship from two different npm packages. A new application starts here:

npx create-flowbite-react@latest

That CLI prompts for the directory name, what template to use, and whether it should initialize a new git repository, so the template choice is a question at the prompt rather than a flag you pass. For a project that already exists, the library package carries its own initializer:

npx flowbite-react@latest init

That one, the README states, sets up all necessary dependencies and configurations in your existing project. The split has a consequence worth noticing: `create-flowbite-react` is published separately from `flowbite-react`, and the component package owns the config writer. When an upgrade rewrites Tailwind settings, plugin registration or the scanned content paths, the code doing it is the same package that ships the components, not a scaffold you can pin once and forget. A team that wants configuration reviewed in version control has to review what this command writes, each time it runs.

Twenty-four framework guides, from AdonisJS to Webpack

The integration list is the strongest part of the README, and its breadth is the point. Twenty-four guides cover server frameworks such as AdonisJS, Laravel, Meteor.js and Modern.js, meta-frameworks such as Next.js, Remix, Gatsby, RedwoodJS, Blitz.js, Astro, Vike and Waku, bundlers such as Vite, Parcel, Webpack, Rspack, Rsbuild, ESBuild and Farm, and the routing and full-stack layers React Router, TanStack Router and TanStack Start. React Server appears as its own entry in that flat list, which says the wiring is not written for a single rendering mode.

The list is flat, with no grouping, which makes it a yes-or-no check rather than a map. What the README does not say is what the init command actually writes for any of those stacks. No config file, no plugin list, no explanation of which Tailwind content paths get registered. Those details live on the docs site at flowbite-react.com, one guide per framework, and the README links there instead of reproducing them. The practical effect: the README settles whether your framework has a guide, and the guide settles whether it has a guide for the way your project is shaped, which matters most when rendering happens on the server or when your Tailwind scan needs an explicit path.

A bun workspace where turbo fans the build out

Contributors work inside a monorepo. The root package.json is a private workspace called root at version 0.0.0, with workspaces spread across `apps/*` and `packages/*`:

"workspaces": [
  "apps/*",
  "packages/*"
],

bun.lock sits at the top and the package manager is pinned to `[email protected]`. Every script delegates to turbo, and the filters name the packages:

"scripts": {
  "build:ui": "turbo build --filter=flowbite-react",
  "dev:ui": "turbo dev --filter=flowbite-react",
  "test": "turbo test"
},

The filter names are not uniform. `build:ui` filters by the published name flowbite-react and `build:cli` filters create-flowbite-react, while the docs site and the storybook workspace are addressed by the aliases `@/web` and `@/storybook`. Alongside sit typecheck, lint, format:check, test:coverage and check-updates, which maps to `npm-check-updates --deep -i`, an interactive upgrade pass rather than a non-interactive CI one. The devDependencies pin the tools behind those tasks, turbo 2.8.2, eslint 8.57.0, prettier 3.8.1 and the changesets CLI 2.29.8. One script deserves caution: clean maps to `git clean -xdf`, which discards untracked and ignored files, taking node_modules and build output with it.

The README header still warns about API changes

Here is the detail a skim misses. The README opens with a banner that states this is a pre-release version and that APIs may change before the final one. Underneath, the registry already carries flowbite-react at 0.12.17 and create-flowbite-react at 1.1.2, with 0.12.16 published on 2026-01-07 and 0.12.17 on 2026-02-09. The scaffolder has crossed the 1.x line while the component library has not, and the banner still describes the pair as unfinished work.

That combination sets the upgrade arithmetic. A 0.x line carries no compatibility promise under semver, and the banner is the project saying so from its own front page rather than a reader guessing. The practical response is to pin the exact version in package.json and treat an upgrade as a code change: read what `npx flowbite-react@latest init` now writes next to what you already have, because the initializer output moves with the version that wrote it.

Where the port stops short and the docs go quiet

Two gaps matter when you evaluate this. The first is parity: components that exist in vanilla Flowbite may not exist here, and the README gallery is a screenshot table that stops partway through a row, so the complete list has to come from flowbite-react.com/docs/components. The second is the contributor and upgrade path. The repository carries storybook among its topic tags and a `dev:storybook` script that filters the `@/storybook` workspace, yet the README never explains how to start it or how props are edited there, so a change to a prop or a theme token is driven from the source and the docs site alone.

Upgrade guidance is thinner. A .changeset/ directory sits at the top of the tree, and the root scripts run `changeset version` and `changeset publish`, so changes are recorded as changesets before they ship. Nothing in the README says how to read pending entries, and the README does not document rollback either. A team crossing many minor versions is left with the Discord invite carried in the header badges as the fastest route to an answer.

Choosing Flowbite's own markup over the React port

The honest alternative is not a competing React library. It is the vanilla Flowbite library the README itself points to through the Flowbite docs at flowbite.com/docs/getting-started/introduction/. The two differ in where behaviour lives. Vanilla Flowbite binds interactivity to markup through data attributes and its own JavaScript layer, which works in any template language, including Blade templates and static pages. Flowbite React moves that behaviour into props, state and render output, so a component can be composed inside your own components, controlled from your own state, and rendered conditionally the way React code expects. That is worth having when the interface is React. It also costs you parity, because the React package has to track a vanilla library moving on its own schedule, and the README already concedes that some vanilla components are missing.

The third option is assembling the same Tailwind utility classes by hand with no component package at all. That keeps full control and removes the upgrade question, but every screen then needs its own markup and its own open, close and focus handling.

Editorial conclusion

Adopt Flowbite React when your stack is React plus Tailwind CSS and you would rather review a set of shared components than re-decide dialog behaviour on every screen. Walk away if you need every vanilla Flowbite component today, since parity is unfinished, or if your team needs a frozen prop API, which the README header explicitly declines to promise. Adoption risk on paper is small: the MIT licence carries no copyleft obligation and the last push landed on 2026-06-27. Verify first by running `npx flowbite-react@latest init` in a scratch branch and reading every file it touches before it touches yours.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. themesberg/flowbite-react on GitHub