tailwindcss: Can't easily get values from config after 1.0.0

Background

Sometimes I like to import my Tailwind config and use the values from it to ensure consistency across the board. One example would be media queries using Tailwind screen sizes when using styled-components:

import tailwind from '../../tailwind'
// ...
export default styled(Component)`
// some css...
@media screen and (min-width: ${tailwind.screens.md}) {
  // more css...
}
`

Problem

With the new 1.0 approach to merging the user config with the default config, it’s not as simple as single import within the project. The configs have to have their function keys resolved and then be merged.

Solution

So I made a little package using resolveConfig() under the hood to merge and resolve the user’s config with the default config.

You can use it like:

import tailwind from 'tailwind-config'

const { theme, variants, ...etc } = tailwind.config('./path/to/tailwind.config')
/* or */
const { colors, screens, spacing, ...etc } = tailwind.theme({ ...configObject })

Here’s the package: davecalnan/tailwind-config

Include this in `tailwindcss`?

This could be added as a first-party feature with some sort of API like:

import { config } from 'tailwindcss'

const { theme, ...etc} = config('./path/to/tailwind.config')

Any thoughts? If it seems like a worthwhile addition I’d be happy to make the PR @adamwathan /@reinink. Otherwise I’ll just leave it as the tailwind-config package as an opt-in for anyone who would like to use it.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 8
Comments: 16 (3 by maintainers)

Most upvoted comments

Like @adamwathan, I noticed that using the recommended resolveConfig was adding ~200kb into my bundled file.

I just needed the breakpoints used by Tailwind, so what I did was creating a Gulp task to generate a breakpoints.json file and then use only that in my JS.

If anyone end up here looking for a way to improve their bundle file size, here is my task:

import resolveConfig from 'tailwindcss/resolveConfig';
import tailwindConfig from './tailwind.config';
import fs from 'fs';

function breakpoints(done) {
  let json = {};

  const fullConfig = resolveConfig(tailwindConfig);

  Object.keys(fullConfig.theme.screens).forEach(key => json[key] = parseInt(fullConfig.theme.screens[key]));

  fs.writeFile(`${paths.src}/breakpoints.json`, JSON.stringify(json), done);
}

BTW, I’m using Gulp 4 with ES6, so all of this is in a gulpfile.babel.js.

thiagorossener on May 2, 2020

Merged that PR so this will be possible in the next beta.

adamwathan on Apr 27, 2019

For that reason, it feels like the safest way to reference your Tailwind config in JS is to split your theme section into a separate file so you can import it without carrying around any other dependency baggage.

While that would work if you were to copy the entirety of Tailwind’s colors and your custom colors to said separate file, what about if you’re only using the extends part of the config to add your custom colors (or sizes or spaces, etc.)?

mikemand on Apr 20, 2019

Thinking about this a bit today, one of the things that was annoying in 0.x was that if you import your whole tailwind.js file into your JS, you end up with a bunch of stuff in your front end bundle that you might not actually need, like any of your Tailwind plugins for example since they are require’d in your config file.

For that reason, it feels like the safest way to reference your Tailwind config in JS is to split your theme section into a separate file so you can import it without carrying around any other dependency baggage.

Or alternatively, we could make it possible to register plugins in your Tailwind config without actually using a require statement, so that you can import your config elsewhere without those dependencies actually being resolved, sort of like how you can do it in a postcss.config.js file — basically just making the file a static object with no dependencies, even if you are pulling in plugins.

Either way we would probably expose our resolveConfig function as public API so people could get the final values.

Anyone have any other ideas on the best way to make this possible while not forcing people to bundle build dependencies into the JS they serve to the client?

adamwathan on Apr 19, 2019

Yes, thanks for creating that package

saintplay on Apr 9, 2019