Is there a plan for resolveConfig in Tailwind 4?

[kennyheard]

With Tailwind 4's CSS-first configuration approach, I would assume that this means the ability to reference values in JavaScript using the built-in resolveConfig function will no longer be possible? Has this been confirmed at all? Have any alternative solutions been discussed, or will it simply no longer be possible?

[adamwathan]

Most of those use cases are covered now by being able to just reference the CSS variables we create for you! Do you have a specific use case where you can't just reference the CSS variables in your JS?

[kennyheard]

Thanks for getting back to me (and so quickly?!).

I was using resolveConfig in a handful of places, but very rarely within templates or components, so I wouldn’t be able to access CSS variables.

On a typical project, I would store the values like so:

export const tailwindConfig = resolveConfig(tailwindConfigFile);

Then use them in a few different ways:

1. Extending Tailwind Merge so that the tool was able to recognise custom classes:

export const tailwindMergeConfig = extendTailwindMerge({
  extend: {
    theme: {
      spacing: objectKeys(tailwindConfig.theme.spacing),
    },
  },
});

2. Creating an object that could be pulled into the headless CMS (Sanity) for colour selection fields:

export const colors = [
  {
    title: "Black",
    value: tailwindConfig.theme.colors.black,
    dark: true,
  },
  {
    title: "White",
    value: tailwindConfig.theme.colors.white,
    dark: false,
  },
] as const satisfies Color[];

3. Utility functions that would reference values like colours or container sizes. As an example, I have one that lets me pass a colour as an argument (typically a value grabbed from a CMS), which then returns a matching accessible text colour based on the colour's dark setting:

...

if (backgroundColor?.dark) return tailwindConfig.theme.colors.white;

return tailwindConfig.theme.colors.black;

...

These are examples taken from a starter boilerplate I've setup, so there would of course be more values involved. Having them all defined in one place in the Tailwind configuration file was a great perk!

[whitespacecode]

+1
I would like to know as well.

[silvenon]

I have a two use case for resolveConfig that I like to do with Vite — referencing screen sizes in:

1. window.matchMedia() calls
2. <img sizes="..."> attribute

// vite.config.ts
import { defineConfig } from 'vite'
import resolveConfig from 'tailwindcss/resolveConfig'
import tailwindConfig from './tailwind.config.js'

const fullTailwindConfig = resolveConfig(tailwindConfig)

export default defineConfig({
  define: {
    ...Object.fromEntries(
      Object.entries(fullTailwindConfig.theme.screens).map(([key, value]) => [
        `import.meta.env.SCREEN_${key.toUpperCase()}`,
        JSON.stringify(value),
      ]),
    ),
  },
})

Then later in my application code:

window.matchMedia(`(min-width: ${import.meta.env.SCREEN_SM})`)

<img src="..." srcSet="..." sizes={`(min-width: ${import.meta.env.SCREEN_LG}) 500px, 200px`} />

These are the only case I can think of where I'm unable to access the values through custom properties, and even though I'm able to access the value of the property on the client side, this way I can reuse it statically without extra logic and be faster, and not cause extra renders in React.

This might be a small reason to bring back resolveConfig, but it also means a lot to me to not have to duplicate the values, or even know what the defaults are.

[joshmossas]

Hello,

I would ask that the tailwind team please consider leaving resolveConfig or some kind of alternative that exposes the values being used by tailwind. Currently I use tailwind as a source of truth for my design systems. And by source of truth I mean it's used across multiple programming languages. resolveConfig is being called as a part of a code generation step to get the final config values and output code in the target language(s).

Here is one such example:
https://github.com/joshmossas/tailwind-to-dart

That is a CLI I made to generate flutter code from tailwind and it's awesome because it means the web apps and mobile apps can share the same design system values even though they are written in different languages. I actually have multiple projects in production that rely on this CLI, and I would really not prefer to have to lock them to tailwind v3 in order to have this kind of cross language codegen.

Also I'm not saying that I need everything to behave exactly the same. I don't mind refactoring to support v4 as long as I can reproduce similar behavior which is: "Use tailwind to define a centralized design system and then being able to generate code for that design system in ____ languages."

I know that my use-case is not the standard, but I hope it at least illustrates some of the value that exposing this sort of functionality provides. By making the internal config / design system accessible in code it allows for extensions in all sorts of places.