[v4] Removing default breakpoints not reflected in plugin() API/method

[flx-sta]

What version of Tailwind CSS are you using?

v4.0.1

What build tool (or framework if it abstracts the build tool) are you using?

• @tailwindcss/cli 4.0.0
• @tailwindcss/postcss 4.0.0
• postcss 8.5.1

What version of Node.js are you using?

For example: v12.0.0

What browser are you using?

v20.13.0

What operating system are you using?

macOS 14.6.1 (23G93)

Reproduction URL

https://codesandbox.io/p/live/27a50c21-9a15-410a-be6e-f846fdbb6102

Run the build script and check the terminal output.

Describe your issue

When defining my @theme with :

@theme {
  --breakpoint-*: initial;

  --breakpoint-phone: 30rem;
  --breakpoint-tablet: 48rem;
  --breakpoint-default: 75rem;
}

I was expecting for only my custom breakpoints/screens to exist.
But instead it's adding them on top of the existing one when definition a plugin:

{
  sm: '40rem',
  md: '48rem',
  lg: '64rem',
  xl: '80rem',
  '2xl': '96rem',
  phone: '30rem',
  tablet: '48rem',
  default: '75rem',
  __CSS_VALUES__: { phone: 0, tablet: 0, default: 0 }
}
≈ tailwindcss v4.0.1

Done in 113ms

---

Unless, is it expected to use the __CSS_VALUES__ object?

[philipp-spiess]

Hey! Yeah this is a limitation of the current backwards compatibility layer as we have to keep an object with the full legacy defaults around and are extending it in the compatibility layer. I'm curious to know what you're building with the plugin API though to see how we can better support this?

[flx-sta]

We are generating classes & variables to be used inside a file-generator and use the exposed objects to extract the available keys.

[philipp-spiess]

@flx-sta Ah, so you have a Tailwind plugin that runs as part of the build steps and spits out other files as side-effects?

The better v4 solution here would be to read CSS variables from the --breakpoint-* namespace at runtime. Would that be possible?

[flx-sta]

@flx-sta Ah, so you have a Tailwind plugin that runs as part of the build steps and spits out other files as side-effects?

Correct

The better v4 solution here would be to read CSS variables from the --breakpoint-* namespace at runtime. Would that be possible?

What do you mean with "at-runtime"? Do you mean reading them with something like .getPropertyValue('--var');?

[philipp-spiess]

What do you mean with "at-runtime"? Do you mean reading them with something like .getPropertyValue('--var');?

Yeah that's what I thought of. Wonder how those files end up being used.

[flx-sta]

What do you mean with "at-runtime"? Do you mean reading them with something like .getPropertyValue('--var');?

Yeah that's what I thought of. Wonder how those files end up being used.

I'm limited in what I am allowed to tell, sorry (NDA).

[philipp-spiess]

Hey! Going to migrate this to a feature request since it's not something we'll be looking into in the short term. Happy to review potential contributions to this, though!