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.

[skysteve]

Do you have a specific use case where you can't just reference the CSS variables in your JS?

Iframe content e.g. embedded payment forms for chargify/stripe etc. The only way I can style these is passing css properties e.g.

  field: {
    width: "100%",
    marginTop:  fullConfig.theme.margin[4],
    height: "100%",
  },

this won't work now

  field: {
    width: "100%",
    marginTop: "calc(var(--spacing) * 4)",
    height: "100%",
  },

I guess technically I can do getComputedStyle(document.documentElement).getPropertyValue('--spacing') but that doesn't feel great performance wise

[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.

[advaitju]

This is quite standard in moderately complex projects in my opinion. Enterprise orgs may have sophisticated solutions that remove the need for a common tailwind.config, but I'm using it to standardise UI's across my company's codebases.

[krstivoja]

Any news on this. Its is needed if you want to create styleguide, or apps around TW

[vildantursic]

Hi,
If resolveConfig is not an option, what would be best solution for getting colors from :root, in case we have light/dark theme in our project?
I tried using getComputedStyle and then getPropertyValue but it is constantly returning :root value, not applied dark theme value of same css variable.

[kerryj89]

This is a friction point for design systems that relied on tailwind.config.ts being the source of truth. Is this something that the Tailwind team would consider adding in the near future (extracting values from the css config) or should we make our own css config parser/resolver?

[julian-scholz]

I would really appreciate that! 👍
In my Angular projects, I liked the ability in v3 to create a separate colors file (e.g. tailwind.colors.ts) and include it in both tailwind.config.js and my Angular component.ts files. This made it possible to have a central location for managing all custom theme properties (in a js object) and to reference the keys directly in all places. Now, in v4, I would have to change several places when using CSS variables and would not receive any compilation errors if a custom theme property reference was changed.

[florianbepunkt]

We have another usecase where we use tailwind inside react-pdf to style PDFs. For this we need to postprocess the theme in JS, which is not possible without resolveConfig.

[chuckjrussell]

+1 for some sort of like-for-like replacement, it looks like the removal of resolveConfig breaks a significant amount of tooling around TW

[selrond]

@adamwathan any news about it? It looks like every other day people come to post here about their usecases

[xban1x]

@adamwathan any news on this?

[fractalf]

I really need to access the theme screen breakpoints, which decides in my app what components to show here and there...

Example:

import resolveConfig from 'tailwindcss/resolveConfig'
import tailwindConfig from '/tailwind.config.js'
const fullConfig = resolveConfig(tailwindConfig)

onBeforeRouteLeave((to, from) => {
    if (window.innerWidth < parseInt(fullConfig.theme.screens.md)) {
        store.main.showMenu = false
    }
})

Another use case

            <div class="flex justify-evenly items-top gap-2 w-full">
                <template v-if="windowWidth >= parseInt(fullConfig.theme.screens['2xl'])">
                    <FilterSearch />
                    <FilterDeveloper />
                    <FilterTag />
                    <FilterFormat />
                    <FilterPrice />
                    <FilterLicense />
                    <FilterRating />
                    <FilterCollection />
                    <FilterSort />
                    <FilterQuantity />
                </template>
                <template v-else-if="windowWidth >= parseInt(fullConfig.theme.screens.lg)">
                    <FilterSearch />
                    <FilterDeveloper />
                    <FilterTag />
                    <FilterFormat />
                    <FilterQuantity />
                </template>
                <template v-else>
                    <FilterQuantity canToggleFilter="true" />
                </template>
            </div>

...I ported my whole app to Tailwind last year, sure hopes this can be resolved somehow! Thanks :)

[andykais]

In case anyone else got here like I did, I thought I needed resolveConfig in order to just access the tailwind colors. It turns out I can just do this:

import colors from 'tailwindcss/colors'

[fractalf]

Thanks. This led me to do some digging and finding what I was looking for! (breakpoints, see below)

[awacode21]

and how do you do that for custom theme colors?

[fractalf]

I did some digging myself...

The tailwindcss npm package exposes a bunch of things, and I had to brute-force to find the breakpoints..

$ cat node_modules/tailwindcss/package.json               
...
  "exports": {
    ".": {
      "types": "./dist/lib.d.mts",
      "style": "./index.css",
      "require": "./dist/lib.js",
      "import": "./dist/lib.mjs"
    },
    "./plugin": {
      "require": "./dist/plugin.js",
      "import": "./dist/plugin.mjs"
    },
    "./plugin.js": {
      "require": "./dist/plugin.js",
      "import": "./dist/plugin.mjs"
    },
    "./defaultTheme": {
      "require": "./dist/default-theme.js",
      "import": "./dist/default-theme.mjs"
    },
    "./defaultTheme.js": {
      "require": "./dist/default-theme.js",
      "import": "./dist/default-theme.mjs"
    },
    "./colors": {
      "require": "./dist/colors.js",
      "import": "./dist/colors.mjs"
    },
    "./colors.js": {
      "require": "./dist/colors.js",
      "import": "./dist/colors.mjs"
    },
    "./lib/util/flattenColorPalette": {
      "require": "./dist/flatten-color-palette.js",
      "import": "./dist/flatten-color-palette.mjs"
    },
    "./lib/util/flattenColorPalette.js": {
      "require": "./dist/flatten-color-palette.js",
      "import": "./dist/flatten-color-palette.mjs"
    },
...

Then you can do this

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

Which will give you this

defaultTheme.screens 
Object { sm: "40rem", md: "48rem", lg: "64rem", xl: "80rem", 2xl: "96rem" }

Then you can do something like this

// util.js
import defaultTheme from 'tailwindcss/defaultTheme'

export const breakpoints = {}

for (const prop in defaultTheme.screens) {
    const px = parseInt(defaultTheme.screens[prop].replace('rem', '')) * 16
    breakpoints[prop] = px
}

// Usage
import { breakpoints } from '@/util'

And you get the breakpoints as they used to be..

https://tailwindcss.com/docs/responsive-design#overview

Hopefully this can be helpfull to someone...

[whitespacecode]

This is great but i don't see how you can change default colors since that is something that @theme does in the .css file.
Importing the @config '../../tailwind.config.js'; doesn't seem to work anymore.

Edit:
@fractalf thanks!
I figured it out.

//Getting a color
import defaultTheme from 'tailwindcss/defaultTheme';

const neutralColors = defaultTheme.colors().neutral;

//Manipulate the colors how you like
//...

//create styles with new colors
const styles = computed(() => {
return `
      :root {
          --color-secondary: rgb(${channels(this.secondaryColor)});
          --color-brand-300: rgb(${channels(this.brandColor
              .desaturate(0.25)
              .lighten(0.15))});
          ${this.newGrays}
      }
  `;
});

//Add the styles to the head
<template>
    <teleport to="head">
        <component :is="'style'" v-html="styles"></component>
    </teleport>
</template>

And then you can access and set them in the css file

@theme {
    --color-primary-300: var(--color-brand-300);
    --color-primary-400: var(--color-brand-400);
    --color-primary-500: var(--color-brand-500);
//...
    --color-primary-gray-500: var(--color-brand-gray-500);
    --color-primary-gray-900: var(--color-brand-gray-900);
    --color-secondary: var(--color-secondary);
}

[chpio]

But that wouldn't work with plugins or yourself changing the settings

[jhirn]

Shame this was removed.

I relied on this for integration with Mantine and charting libraries. It was really nice for grabbing color ranges as an array. Would love to see this added back or a library to replace the functionality. I'll have to write one but it probably won't be complete enough to open source.

[Ashkar2023]

Why remove something that is a legit way of doing things?
Bring back resolveConfig.

[dealer-solutions-gene]

I adore finding these kinds of threads after upgrading a product and finding something random break.

This function was amazing for fetching custom tailwind screen breakpoints at runtime from the config and turning them into my own hooks in other react components not just for styling. I used this to include/ommit components based off screen size.

https://tailwindcss.com/docs/upgrade-guide#theme-values-in-javascript

We've removed this in v4 in hopes that people can use the CSS variables we generate directly instead, which is much simpler and will significantly reduce your bundle size.

[kostenickj]

absolutely insane that this was removed. I need to access my colors to send branded emails on the SERVER so obviously i cannot use getComputedStyle. Now i have to define my colors in 2 spots. Add it back.

[FredrikZeiner]

If you want to use the default values in the theme, you can import the default theme:

import theme from 'tailwindcss/defaultTheme';

I still have not found a solution for resolving the extended config though.

[el-schneider]

Using the defaultTheme is unfortunately not quite the same. I'm also – in various of my projects – relying on being able to getting the actual (resolved) breakpoints in my postcss config

[tachibanayu24]

Just jumped back into Tailwind and was surprised resolveConfig() is gone.

I still need the fully-resolved theme in JS—for example, to pass a brand color into a component and let its props be type-safe:

<Component color={colors.brand[500]} />

[ozmos]

Was in the middle of a side project that relied on resolveConfig(). All my grand plans, gone 🥲

[Ashkar2023]

I'm trying to understand how Tailwind v4 handles theme resolution internally so I can recreate resolveConfig in a standalone way. I assume that v3 had everything in JS and you could inspect/transform the config easily, but v4 seems to generate utilities dynamically using CSS variables and base values.

I don’t fully understand how the internals work now — if anyone has insights, pointers, or even rough directions on where to start digging, I’d really appreciate it. Just trying to figure out if resolving the full theme is even possible anymore.

[minht11]

Current solution of using getComputedStyle works fine at runtime in the browser, but in server I can't access it so still feels like api is still missing something. For example I want to generate favicons with correct color scheme from tailwind config.

[reverberedechoes]

I created my own personal resolveConfig with only the data I needed (colors and screen sizes). Feel free to use it. You'll have to change the path of the tailwind.config.js.

Lodash or a deepMerge function will be needed.

import defaultTheme from "tailwindcss/defaultTheme.js";
import merge from "lodash.merge";

// Change with your own path
import tailwindConfig from "../../tailwind.config.js";

export const resolveConfig = () => {
  // Colors
  const baseColors = defaultTheme?.colors() || {};
  const extendedColors = tailwindConfig?.theme?.extend?.colors || {};
  const colors = merge({}, baseColors, extendedColors);

  // Screens
  const baseScreens = defaultTheme?.screens || {};
  const extendedScreens = tailwindConfig?.theme?.extend?.screens || {};
  const screens = merge(baseScreens, extendedScreens);

  return { colors, screens };
};

[joshdavenport]

The idea of reducing users bundle size and simplifying JS based Tailwind reflection is admirable but having no resolveConfig story in v4 is effectively a deprecation given there is information that simply is not added a CSS variable, ever. You can't access final breakpoints used, they are simply never added as a variable in any case. No access to theme variables that have not been used, but maybe they will be in the future. I'm sure there's more that don't come to mind right away.

This kills dead some really useful techniques: reflecting on the theme at runtime, doing some work on the server, generating types as part of a workflow. I'm sure there's more to mention here too.

[marty0678]

Yeah this has been a blocker for me from upgrading from v3, and now that more libraries and frameworks are moving over to v4 it's starting to block me from upgrading other packages now too. Really hoping something is worked out here.

[jshxr]

I get that Tailwind v4 is all about leaning more into native CSS, simplifying the API, and probably cleaning up the internals along the way. I also like the simplicity of defining themes with CSS variables directly instead of relying on a config.js file.
That being said, as this thread shows, there are still plenty of use cases where the theme needs to cross over from CSS-land into JS-land or even beyond without any access to the CSS variable definitions. So having a built-in solution for that would be really helpful.

Instead of resolving the config at runtime, how about generating a plain JS object (+ .d.ts) at build time as an optional step? This keeps built-time dependencies where they belong, with the only impact on the client bundle being the JS object itself, which can then be directly accessed in code.

In the v3 docs, it was even recommended to move resolving the config from runtime to build time using tools like babel-plugin-preval. First-party support for this in the Tailwind CLI, as well as the PostCSS and Vite plugins, would reduce friction and improve the DX. It might also make integration with editor extensions like the VSCode Tailwind extension easier, enabling up-to-date autocomplete for the JS object whenever a new CSS theme token is added or removed.

(Disclaimer: I've never looked into Tailwinds internals nor have I ever written a PostCSS or Vite plugin, so this may be wishful thinking. But maybe at least some of it is feasible)

[jshxr]

And while I'm at it with my wishful (and possibly infeasible) thinking, how about automatically detecting if that build step is needed by analyzing the imports, looking for a

import { theme } from "tailwindcss/theme"
// eg. accessing --color-text
const textColor = theme.colors.text

or wherever that theme object ends up being exposed. The object would only be generated and included in the bundle if there's at least one such import. While this would increase the internal complexity yet again, the DX would be unmatched.
(This would be more about reducing the time it takes to build, rather than reducing client bundle size, since most bundlers would drop the unused object anyway)

Tailwind is already doing a lot of magic behind the scenes, so what's a little more? 😄

[joshdavenport]

Codegen would be a solid compromise, this is a nice idea. If all of the JS land stuff happens as part of development/CI then bundle size doesn't even come into the picture. It takes something that was always a little jank (totally get that about resolveConfig and it's usage) to something more concrete. Type generation as a further step to this would be incredibly useful.

[boycce]

This holding up React Native libraries using Tailwind, e.g. tailwind-react-native-classnames

[TehBrian]

Currently needing to use colors from Tailwind on the server (which rules out getComputedStyle) for server-side document (non-HTML) rendering. Duplicating theme colors in both Tailwind and in server JS feels frustrating because I'd ideally like a single source of truth, and Tailwind (prior to resolveConfig's removal) served that function well.

[ikluhsman]

My use case is simple: define custom colors in tailwind.config.ts then switch color schemes out based on page routes or just a config palette where the user can switch colors themselves. Problem being, I can't access my custom color values in the tailwind.config.ts without resolveConfig.

My workaround is to use the CSS variables as recommended by Tailwind:

[main.css]

 /* source the variables needed inline with Tailwind defaults */

@source inline("bg-avocado-{50,{100..900..100},950}");

/* define new CSS color variant */

@theme {
  --color-avocado-50: oklch(94.64% 0.125 130.87);
  --color-avocado-100: oklch(89.7% 0.241 129.78);
  --color-avocado-200: oklch(81.19% 0.218 129.73);
  --color-avocado-300: oklch(72.69% 0.195 129.82);
  --color-avocado-400: oklch(64.25% 0.173 129.86);
  --color-avocado-500: oklch(55.85% 0.15 129.81);
  --color-avocado-600: oklch(47.39% 0.128 130.01);
  --color-avocado-700: oklch(38.95% 0.104 129.66);
  --color-avocado-800: oklch(30.34% 0.081 129.52);
  --color-avocado-900: oklch(21.8% 0.058 129.62);
  --color-avocado-950: oklch(17.39% 0.047 130.24);
}

You can then set something like --ui-primary: avocado; or use an array of your customized color values. I assume you can do this as well with breakpoints, fonts, etc. With CSS you shouldn't really need to dig into your config in order to apply dynamic or custom styling. There are still good use cases where resolveConfig might be useful.

Hopefully this is helpful for those who have used resolveConfig to deliver dynamic style changes within the client.

All that said, in my opinion we still need a way to expose config values and, hopefully, without bundling/delivering half of tailwind to the client.

[TheKnarf]

The removal of resolveConfig broke our Storybook setup where we use it to preview colors and typography settings in a dynamic way.

[ggroupas]

I just run to this problem when trying to find the breakpoints I have set ( not the defaults ). I think there should have been an easier way to do this using tailwind tools @adamwathan.

For anyone in the same position, to get the values in an object I did

1. Use theme static

Object.entries({ ...window.getComputedStyle(document.body) })
   		.filter(([_, value]) => (value as string).startsWith('--breakpoint-'))
   		.map(([_, value]) => value as string)
   		.reduce((obj, cssVar) => Object.assign(obj, {
   			[cssVar.replace('--breakpoint-', '')]: window.getComputedStyle(document.body).getPropertyValue(cssVar as string)
   		}), {});

In the same fashion you could find other values

[Uanela]

This simply worked just like magic on V4, as @adamwathan stated here #14764 (comment). Just use the CSS variables created by tailwindcss.

[mxswat]

Are there any updates regarding the resolveConfig feature in Tailwind 4?

[selrond]

@adamwathan has confirmed they don't plan adding such feature to Tailwind.

[kerryj89]

Welp. While waiting I used https://styledictionary.com/ but it's a lot more work than having a config be the source of truth since you have to export it to various formats (one for Tailwind to understand, one as object that your theme provider can understand, etc).

[marty0678]

While I respect the decision, it's quite disappointing. We've been waiting for over a year based on it being a possibility to be fixed. It should have just been labeled as a breaking change and just told us to move on last year instead of waiting for a fix as it was previously stated that they would add support back for this if there were use cases which this issue has shown there were.

It's still a blocker for many of us to upgrade to Tailwind v4, as many of us have built systems on top of this previously supported feature.

At least we have an answer now, and can reschedule our roadmaps accordingly to rebuild our systems that rely on this, likely resulting in the lack of a source of truth.

Regardless, appreciate all the work the Tailwind team does.

[ozmos]

Well that sure sucks

[selrond]

@kennyheard I think you can mark this as answer to the discussion you’ve started, so people will see it right away

[kennyheard]

Thanks, @selrond! 🙏🏻