How can I disable arbitrary properties?

[LZL0]

I am having some issues with a legacy website's gulp configuration. For the staging server, I used to generate all the styles to make development easier. Since arbitrary properties, such as w-[100px], were added gulp fails to generate the stylesheet.

How can I disable arbitrary properties? Could you guys please point me in the right direction?

[wongjn]

Just to be clear, do you mean arbitrary properties, like [width:100px] or arbitrary values, like w-[100px]? Either way, you can:

• Use the blocklist to discard would-be rules for classes individually.
• Replace the core plugins that use matchUtilities() and replace their registrations with addUtilities().
• Use a PostCSS plugin that runs after Tailwind that matches and discards rules based on a pattern of their selector.

[LZL0]

Thanks for the reply.
I would like to disable both of those.
I used to run this selector, I presume this is what I need to update, provided that there is no other clear way to disable those two features in the config:

safelist: [
        {
            pattern: /./,
            variants: [
                "hover",
                "focus",
                "print",
                "sm",
                "md",
                "lg",
                "xl",
                "2xl",
            ],
        },
    ],

I am going to update this thread as I collect more info.

[paulgv]

We'd also be interested in a configuration option to disable arbitrary values 👍

[MPJHorner]

👍

[scr2em]

This is still a valid concern, I want to limit our developers to the design tokens

[uclaeamsavino]

We just ran into this problem. A dev has h-[64] (which should be h-[64px]) in one of her className properties:
<div className="fixed top-12 left-0 right-0 z-40 h-[64] py-3 px-4">

On her local, the height displays correctly as 64px:

However on our AWS Amplify-hosted nextjs server, h-[64] fails and the style is blocked:

I've spent the last couple hours googling and hallucinating with ChatGPT and it seems like there's no simple fix for this? How can we know that what we see on our local is correct if it fails on the server? I even got the eslint tailwind plugin working and it found a bunch of other invalid tailwind class names, but it didn't trigger on h-[64].

This is a real problem if we can't get local to fail in the same way the server would fail. This time it was pretty obvious. But I could see hours of head-scratching in the future trying to figure out why the server is failing.

[uclaeamsavino]

Thank you for the well-thought-out reply. It's good to know that h-[64] should always fail and this isn't the expected behavior of tailwind in dev mode.

However, something is causing h-[64] to not fail for us locally:

I will investigate and see if I can find the source of this, or put together a demo.

[uclaeamsavino]

Okay, I have more clues about what's happening. When I run next build locally, it creates a .next folder. When I search that folder for h-[64, I only see this file where the class name is not corrected:

If I then run next start locally to run the production build, the class name is not corrected and I see the CSS error.

However, if I run next dev --turbopack locally, and then hit the site, the JIT compiler creates a new globals.css file, where apparently it "fixes" the broken class name:

So this is definitely the source of our issue. For some reason the class name is getting corrected in dev mode only. I'd love to just turn off whatever is doing that fixing. Dev should be stricter or as strict as production, never less strict.

[uclaeamsavino]

Update: Removing --turbopack from the next dev call causes the class to not get fixed. So it's something turbopack is doing or calling. We are on next 15.5.4 which uses webpack by default. The investigation continues.

I fully realize that ChatGPT might be hallucinating all of this. But just for reference, this is what it says:

[rozsazoltan]

@uclaeamsavino Aha, I took a look.

Turbopack API Reference - Lightning CSS: In Use

It seems that Turbopack runs the result through LightningCSS in the background. That's why, in development mode, Lightning CSS "magically" converts the invalid value 64 into 64px.

Under the hood Tailwind uses Lightning CSS to process nested CSS.

TailwindCSS does this as well, but only during the build process - whereas Turbopack does it even during development.

I think this is bad practice, and the simple solution (use [64px], [4rem], etc.) is to just avoid using invalid length values (e.g. [64]).

As for why it doesn't become 64px again in the build output, I haven't figured that out yet. In theory, with the TailwindCSS configuration, Lightning CSS should also correct the invalid length values during the build.

• Lightning CSS playground

[uclaeamsavino]

Well as it turns out, we weren't using the --turbopack option for next build. We were only using it for next dev. And the mystery is solved as to why we weren't seeing this issue in our server running the build, but were seeing it locally running dev.

I inherited this project and that's how it was set up. I assumed --turbopack was just something for dev use. Now I just have to decide if I want to add --turbooack for both options (nextjs 15.5.x) or for neither option. Do you have any strong opinions on that? I guess getting used to turbopack now might make more sense for when we upgrade to nextjs 16, where it's the default.

Thank you so much for jumping in on this and helping me debug our setup. I really appreciate it.

[MaxPrehoda]

For anyone still looking for this: as far as I know there's still no setting to turn arbitrary values off, so the practical way to keep a team (or an AI agent) on your design tokens is a lint check that fails CI. A few options:

• eslint-plugin-better-tailwindcss has a no-restricted-classes rule that can ban any class matching a pattern like -[.
• @shadcn/lint has no-arbitrary-values and no-raw-colors, and runs on ESLint or Oxlint, with Vue and Svelte support through their parsers.
• If you'd rather not set up ESLint, I wrote a plain Node script that reads template files as text and flags arbitrary values, hex codes, off-scale spacing and font sizes, and raw palette colors like text-neutral-700. It's part of a set of agent skills (https://github.com/MaxPrehoda/motif), but the script works on its own. To see what it finds without installing anything:

curl -sL https://raw.githubusercontent.com/MaxPrehoda/motif/main/design-lint.mjs | node --input-type=module -

Whichever you pick, on an existing codebase record the current count first and only fail CI when it goes up. Otherwise the build is red on day one and people stop looking at it.