themesberg / themesberg/flowbite-react

Tailwind v3/v0.10 -> Tailwind v4/v0.12 migration silently removes global form styles

Open
#1,677 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
2.1k
Forks
506
PR merge metrics
No merged PRs in 30d

Description

We ran into a fairly subtle migration issue upgrading from:

  • Flowbite React v0.10.x + Tailwind v3
    to
  • Flowbite React v0.12.x + Tailwind v4

and wanted to document the findings and ask for guidance on the intended migration path.

What changed for us

After upgrading, a number of input fields across our application suddenly lost their styling (especially padding/spacing), including components that do not use Flowbite React at all.

Initially this was confusing because the affected components were unrelated to Flowbite.

After tracing through the generated CSS, we found that the old integration path implicitly injected global form styles, while the new Tailwind v4 integration no longer does.

Flowbite React 0.10 injects global styles

With Tailwind v3 we had:

const flowbite = require("flowbite-react/tailwind");

plugins: [
  flowbite.plugin(),
]

It seems that flowbite.plugin() internally routed through the standalone flowbite/plugin.

That plugin appears to have had forms = true enabled by default and injected global base styles via addBase(...), including selectors like:

[type='text'],
[type='email'],
textarea,
select {
  padding: .5rem .75rem;
  ...
}
Flowbite React v0.12 no longer creates global stzles

With Tailwind v4 / Flowbite React v0.12 the recommended setup is

@import "flowbite-react/plugin/tailwindcss";
@source "../../.flowbite-react/class-list.json";

This new CSS-first integration path no longer appears to route through the standalone flowbite/plugin, and the global form base styles disappear.

As a result:

  • unrelated inputs lose padding/styling
  • applications may experience visual regressions outside Flowbite components
  • the migration impact is difficult to trace back to Flowbite
Questions
  1. Is this an intended behavioral change? Is my analyis correct that flowbite v0.10 injected global styles?
  2. Is there an officially recommended migration path for users who implicitly depended on the old global form reset behavior?
  3. Would it make sense to mention this in the migration docs / compatibility docs?

This was particularly difficult to debug because the regressions appeared in components that did not use Flowbite at all.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the legacy flowbite-react/tailwind and flowbite/plugin setup with the Tailwind v4 flowbite-react/plugin/tailwindcss import and .flowbite-react/class-list.json path described in the report. Verify whether the form selectors and global styles differ, then identify the migration or compatibility documentation that should explain the behavior and recommended replacement. Done means the intended behavior and migration guidance are documented clearly.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, tailwindcss
Domain
documentation
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.