Add the default container sizes to the default theme

[mririgoyen]

What?

This PR adds the default container sizes to the exposed defaultTheme to coincide with the documentation.

container: {
  '@3xs': '16rem',
  '@2xs': '18rem',
  '@xs': '20rem',
  '@sm': '24rem',
  '@md': '28rem',
  '@lg': '32rem',
  '@xl': '36rem',
  '@2xl': '42rem',
  '@3xl': '48rem',
  '@4xl': '56rem',
  '@5xl': '64rem',
  '@6xl': '72rem',
  '@7xl': '80rem',
},

Why?

The defaultTheme exposed by Tailwind v4 includes an empty container object. However, the documentation defines what the default container sizes are.

Because there is no resolveConfig option in v4 (see this discussion for more on that), when creating utilities, it may be necessary to refer to the default theme in JS.

import defaultTheme from 'tailwindcss/defaultTheme';
console.log(defaultTheme.screens);
console.log(defaultTheme.container);

[philipp-spiess]

Hey! The JavaScript defaultTheme is for compatibility with v3 only. In v3, we did not include container sizes by default: https://git.1-hub.cntailwindlabs/tailwindcss/blob/v3/stubs/config.full.js#L190

We decided to keep the values here mostly similar to avoid breaking older examples. This is not meant to be a JS representation of the default styles from theme.css in v4 I'm afraid. For that we try to do our best to get the runtime values right (passed through to the plugin API) but since the theme isn't a JavaScript object anymore, this is not something that'll have a 1:1 mapping anyway.

Because of that, we'll likely not going to add these values to this export. I'm curious what you use this export for, though?

[mririgoyen]

I'm curious what you use this export for, though?

I maintain a design system component library. The source of truth is the Tailwind config. It contains all the theme colors, font declarations, screen breakpoints, container breakpoints, etc.

As part of the component library, there are certain React hook utilities for monitoring breakpoints (in our case useBreakpoint and useContainerBreakpoint respectively), that require knowing all available breakpoints in code. Being that both of these utilities are client-side hooks, there might be an avenue for them to be sniffed out of the DOM via getComputedStyle, but we'd have to know and hard-code each property to lookup via getPropertyValue, it would be another round trip in the DOM (which is a performance hit), and we'd have to specifically set a @theme layer as static that included the breakpoints to ensure all variables are always available. None of that is ideal for what could simply be a dictionary lookup.

However, the biggest problem is that the component library is used within a Next.js application, in which the screen breakpoint values are required in the next.config.js when setting up things such as image optimization settings. There is no DOM to lookup here; the values need to be importable.

We need a single source of truth for our design configuration, and naturally that should be the Tailwind configuration. However, in v4 resolveConfig was removed and there is only preliminary conversation about whether or not a new method will be added to provide similar functionality in the future.

Okay, so long story to get to why we need this export...

Luckily, for screen and container breakpoints, we utilize the Tailwind defaults. Because of that, we found that we were able to use the defaultTheme export to get some of the values we needed.

import defaultTheme from 'tailwindcss/defaultTheme';

const nextConfig = {
  ...,
  images: {
    deviceSizes: Object.values(defaultTheme.screens).map((screen) => parseInt(screen) * 16)
  },
  ...,
};

Note that this only works because we use the defaults. If we defined our own breakpoints, we'd have no other choice but to duplicate configuration code.

However, missing from the defaultTheme is the container queries defaults, thus this PR.

---

All that being said, if this is not something you're willing to add into the defaultTheme as it was due to a v3/v4 compatibility layer, I understand that. I just wanted to make sure you had a solid example of the why so it can help drive future utilities needed by your users. I also would welcome any suggestions on how we might get around this limitation until a solution is added to Tailwind v4.