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.

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

[kerryj89]

@adamwathan Thanks for all you do!

[krstivoja]

Thanks a lot! @adamwathan

[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

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

[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);
}

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