[v4] add support for disabling core plugins

[phegman]

Disabling core plugins is not available in v4 - https://tailwindcss.com/docs/upgrade-guide#disabling-core-plugins

This is a blocker for us to upgrade as we disable a few core plugins so that they don't conflict with some of our custom utils. One example is the container plugin since we have our own container classes and don't use the Tailwind ones. Another one is the ring plugins. We have a custom ring class that enforces our design system so we disabled to ring plugins to avoid confusion and conflict.

Is this feature planned? Are there any existing workarounds?

[ssang]

I agree we need support to disable these through configuration.

In the mean time, for the container plugin, as far as I can tell the only utility it provides is the max-width. The snippet below should disable it completely

@utility container {
  @media (min-width: theme(--breakpoint-sm)) {
    max-width: none;
  }
}

[jbasoo]

This is quite a subtly hostile change from v3. It was previously possible to configure core plugins in an opt-in fashion to reduce clashes with other CSS and have tighter control over the output. The "all or nothing" approach is sad to see.

[ShaneYu]

One of the biggest issues I am facing, due to the inability to disable built-in/core utilities, is that I cannot stop the dynamically generated border width utils like border-1, border-t-2 in favour for our design system border width sizing of border-thin, border-t-thick etc.

There are several other utils where we want to replace the default ones with tshirt sizes etc.

[ssang]

Looks like Tailwind 4.1 introduces the ability to disable utilities using @source not inline('container')

[luca-peruzzo]

you can disable them, but you aren't able to redefine them.
something like this:

@import "tailwindcss";

@source not inline("p-{0..96}");

@theme inline {
  --size-0: 0px;
  --size-1: 4px;
  --size-2: 8px;
  --size-3: 12px;
  --size-4: 16px;
  --size-5: 20px;
  --size-6: 24px;
  --size-7: 28px;
  --size-8: 32px;
  --size-9: 36px;
  --size-10: 40px;
  --size-11: 44px;
  --size-12: 48px;
  --size-14: 56px;
  --size-16: 64px;
  --size-20: 80px;
  --size-24: 96px;
  --size-28: 112px;
  --size-32: 128px;
  --size-36: 144px;
  --size-40: 160px;
  --size-44: 176px;
  --size-48: 192px;
  --size-52: 208px;
  --size-56: 224px;
  --size-60: 240px;
  --size-64: 256px;
  --size-72: 288px;
  --size-80: 320px;
  --size-96: 384px;
}

 
@utility p-* {
  padding: --value(--size-*);
}

will throw an error on p- class usage

[ssang]

@luca-peruzzo This might feel hacky but this was possible before the update

@theme {
  --size-0: 0px;
  --size-1: 4px;
  --size-2: 8px;
  --size-3: 12px;
  --size-4: 16px;
  --size-5: 20px;
  --size-6: 24px;
  --size-7: 28px;
  --size-8: 32px;
  --size-9: 36px;
  --size-10: 40px;
  ...
}

@utility p-* {
  padding: calc(--value(integer) * 0); /* Reset the default utility so that any integer amounts to zero */
  padding: --value(--size-*); /* If the value is available in the defined scale, it will reference it */
}

First party support to completely reset a utility class namespace would be helpful though so you don't have to figure out how to reset it through CSS yourself.

[quentin-benyahia]

I’m really frustrated with this change. I relied on disabling the container core plugin to customize things my way, and now in v4 that option is gone. What’s the workaround here? I tried everything in this convo and they all got drawbacks, this feels like a major setback for those of us who need that flexibility. I might just update the name to something like "container-custom" and update it around in my app, which piss me off.

[jbasoo]

That's what's frustrated me too. Tailwind seems to have moved from being a tool/library that doesn't dictate how you architect other parts of your app to being a full-fat framework you have to build on top of.

[ssang]

What's the drawback to @source not inline('container')?

[hobiah]

Is there a way to avoid inline property, such as:

@property --tw-backdrop-saturate
@property --tw-gradient-to-position

using @source not inline

[GrimLink]

@ssang that you can't add your own utility class named .container

[acalvino4]

Shortly after the v4 release I got a brief response from @philipp-spiess that they would be thinking this through (as well as ability to replace such utilities).

Given that, as many here have pointed out, this is a breaking change, and that we are coming up on a year since the v4 release, it would be awesome if the maintainers could weigh in on the direction here (or better yet, document it on the website). I think the strongly opinionated defaults are awesome, but I think the ideal for a framework this widely used would be that users can customize what utilities are not allowed, or even override them when appropriate for their team/use-case.