Tailwindcss: [Feedback Requested] How should the CLI work for v1.0?

[adamwathan]

One of the biggest changes in v1.0 is that we will be encouraging people to only customize/extend the parts of the default config they'd actually like to change, so they will have a much smaller config file at the end of the day than they do now. We don't want to automatically force people to own all of Tailwind's default config as soon as they create a config file, so the question is:

What should tailwind init actually do in v1.0?

My initial thoughts are that it should create a pretty minimal config file, maybe something like this:

module.exports = {
  theme: {
    // Some useful comment
  },
  variants: {
    // Some useful comment
  },
  plugins: [
    // Some useful comment
  ]
}

...or maybe not even that much.

Some folks have expressed the desire to still scaffold out the entire config like in the 0.x days too, which I think I'm fine with supporting as an option. Maybe a separate tailwind eject command that merges the default config with your existing customizations and writes that out to your config file, with perhaps an --eject flag that you can pass to init to do it from the beginning?

[stefanbauer]

It totally makes sense to me to provide an option to eject it. Personally, I like the code snippet above as a minimal config file. Otherwise, you have always to look at the docs to create that, even it's very simple.

I was one of the guys who voted to keep the configuration file. I use it very often as a reference. It is fast and simple. So if that option would be still available, I'd be more than happy.

[MattStypa]

Config merging

While this behavior is convenient I feel that it promotes a hidden behavior. A simpler and more powerful approach is to ask users to explicitly spread the default config.

My recommendation is to keep the current behavior for graceful configuration recovery but in all examples and documentation use the spread operator.

// tailwind.config.js
const default = require('tailwindcss/defaultConfig')

module.exports = {
  ...default,
  theme: {
    ...default.theme,
    // Some useful comment
  }
} 

Consolidate config and theme

When using the above approach there is no need to keep config and theme as separate modules.

init command

The init command would generate the example above at the minimum. Having the spread operators there indicates where to look for available options.

eject should probably be --full

eject as used by other frameworks, indicated unreversible operation. This is not the case with Tailwind.

npx tailwind init --full [filename]

[hacknug]

I'm going to be using my custom default config 95% of the time so we definitely need something like --full or eject. I agree with @MattStypa that eject might not be the right term for this.

Also, if we're still going to allow users to extend their config files, maybe we should just have that there instead of spreading the defaults in?

[brookback]

I'd vote for providing an option to generate a default, full config with --full. I can definitely feel for a case where I wanna start off with all the things from Tailwind and remove/modify the things I see there. Doing a minimal config file only would force me to go back and forth to the docs and copy paste config names (blergh).

[thecrypticace]

Something I'd also like to see is a version of tailwind build that supports PurgeCSS (if you have it installed) and maybe the .postcssrc.js file if available.

I'd be 👍 to PR this if you think it'd be useful.

[adamwathan]

What we have now is pretty good I think, tailwind init for simple config, tailwind init --full for full config.