Adding a custom prefix for tailwind 4.0

[DennisVulders]

Hey All,

We are currently upgrading our code from tailwind 3 to tailwind 4 and we (like many others) use the "tw-" prefix. While after searching for a while i did find out that prefixes can be added but it would then be used as tw:width-full for example. To make tailwind 4 more backwards compatible and in my personal opinion i think the readability of the "tw:" is worse than the "tw-" prefix, since the classes themselves are also kebab-case.

I know that we can still use the old config to do this, but it would be ideal if it is possible to use:
@import "tailwindcss" prefix(tw-); So that we can all use tw-w-full etc.

Hopefully this can be a feature in a future release of tailwind 4.x 🙂

[landykos]

@DennisVulders how do you set the prefix?

[landykos]

@DennisVulders Just tested your theory and this is working for me.

@import "tailwindcss" prefix(tw);

[DennisVulders]

Can you write the classes like this now? tw-w-full
because when i use @import "tailwindcss" prefix(tw); it only allows me to write the syntax like this tw:w-full

Could you share a https://play.tailwindcss.com/ link if you have it working with the dash instead of a column?

[landykos]

@DennisVulders After more testing we found that the only way we could get it working was with the syntax tw:w-full would be great to set it to tw- but could not get that working.

[anburocky3]

Have you figured out the way?

[t0dorakis]

I would also be interested, we have issues with scoping micro-frontends with different tailwind versions 👯

[rozsazoltan]

The prefix became a variant starting from v4, so Tailwind can now apply it at the very beginning of every class name. For example, in v3: tw-text-sky-500 hover:tw-text-sky-800, whereas from v4 onward: tw:text-sky-500 tw:hover:text-sky-800.

From a readability standpoint, it's debatable which approach is better, but in terms of functionality, handling it as a variant fits much more naturally into the TailwindCSS syntax than the v3-style prefix. I believe this won't change from v4 onward, and it won't be possible to revert to using the old prefixes.

[t0dorakis]

Maybe I'm on the wrong track in general, we searching for a way to scope a child-frontend with the help of prefixes so no parent (v3) to child (v4) class overrides are happening. In the best possible universe the class-prefixing would be handled during the compilation so nobody has to rethink the way classes are written in TW. If you have a solution in mind, I would be eager to hear about it!

[t0dorakis]

I figured out a way that works for my use-case — thanks for the reply though!

// global.css
@import './scoped.css';
@import 'tailwindcss/theme';
 
// scoped.css
#app {
  @import 'tailwindcss/utilities';
}

[phegman]

We use Tailwind at GitLab and this is a bummer for us as we use the gl- prefix. It would be a pretty large undertaking to migrate all instances of our prefix to the new format and it is a pattern we have had for a long time so switching to the new format would be a shift for all our engineers. I am also not sure what the migration strategy would be for us since it is not feasible to update all instances in one MR and migrate to v4 at the same time.

Would you consider making this configurable? I would be happy to take a stab at opening a PR 🙂

[KhaledMohamedP]

@phegman were you able to work around this issue or find a solution for it?

[phegman]

@KhaledMohamedP we have not. We are still on v3 for now until we figure out a way to iteratively migrate. We probably have 20,000+ CSS classes with a gl- prefix which we cannot migrate in one MR as it will never merge due to merge conflicts. We may be able to do something creative by running v4 and v3 at the same time but haven't dug into it yet.

[willmartian]

Similar to the above. At @bitwarden, I am considering keeping the company on Tailwind 3 due to the difficulty/size of the migration. Perhaps having a config option would allow us to tackle the migration incrementally?

[RobinMalfait]

What kind of issues are you running into right now? Is it because the PR would be too big, or is it because it's spread across multiple repositories?

When you want to tackle the migration incrementally, what does that mean for the issues you are running into right now?

[gianluca-vedovato-24]

I'm in the exact same boat. We currently manage multiple repositories that all rely on a single, shared Tailwind configuration using the tw- prefix.

Upgrading to v4 is currently a blocker for us because migrating away from this prefix isn't a simple find-and-replace task. Dealing with nested modifiers and variants across thousands of files in different active codebases would be extremely error-prone and would trigger endless merge conflicts for our teams.

Are there any updates on whether customizable prefix separators (or specifically supporting tw- style prefixes) are on the roadmap for v4?
It would be incredibly helpful to know if there is a realistic chance this will be supported in a future v4 minor release. If not, we'll likely need to stick with v3 for the foreseeable future so we can plan our technical debt accordingly.

Thanks to the team for all the incredible work on v4 otherwise!

[ethan2328]

For large-scale applications, maintaining the kebab-case prefix (tw-) is crucial for both readability and keeping a smooth migration path from v3. The jump to the variant colon separator (tw:) introduces unnecessary friction for existing codebases. Having this be configurable would drastically increase v4 adoption rates for enterprise projects.