Allow users to override a core plugin's configuration

[adamwathan]

This PR makes it possible for users to completely override a core plugin's configuration by providing a configuration object in the corePlugins section of the config file.

module.exports = {
  // ...
  corePlugins: {
    fontSize: {
      variants: ['responsive'],
      values: {
        sm: '0.875rem',
        md: '1rem',
        lg: '2rem',
      }
    }
  }
}

This configuration overrides any configuration that would be derived from the theme and variants sections.

Right now this isn't really useful but it's part of the vision outlined in #637. It's at least necessary to be able to set a core plugin to false to disable it, and it's very possible that in the future some core plugins expose additional advanced configuration that is only accessible through corePlugins for users who want to do something very custom (like change a class name) and deviate from the Tailwind's defaults significantly.

[MichaelDeBoey]

@adamwathan So by this PR you have 2 ways of defining the wanted variants?
In the root variants and in the corePlugins config?

[adamwathan]

Sort of — if you specify an object for a plugin in the corePlugins config it will override whatever you have set in both the theme and variants sections.

These two config files produce the same result:

// Config A
module.exports = {
  theme: {
    opacity: {
      '0': '0',
      '50': '.5',
      '100': '1',
    }
  },
  variants: {
    opacity: ['responsive', 'hover'],
  }
}

// Config B
module.exports = {
  corePlugins: {
    opacity: {
      variants: ['responsive', 'hover'],
      values: {
      '0': '0',
      '50': '.5',
      '100': '1',
    }
  },
}

There's no real benefit to this currently because every plugin option is already available via theme and variants, but if I ever decided to add more advanced options to each plugin (like customizing the class name for example), that would probably not be exposed through theme or variants and would instead be configured here.

Really the only other reason I've made this work is because we have this corePlugins section primarily to make it straightforward to disable core plugins using false, and it just sort of feels right that you could also use it to configure the core plugins directly instead of using the theme and variant abstractions.

Maybe it's pointless though and false should be the only thing you can really do there.

[MichaelDeBoey]

@adamwathan Isn't that a bit confusing to have 2 different ways of doing the same thing? 🤔

I understand the "additional options" idea, but find the possibility to have them in both variants and corePlugins a bit confusing, because I have to know which one will win the battle

Just my 2c btw, glad you're taking so much time to provide us with a nice API and a nice framework tho! 😉

[adamwathan]

Yeah I wouldn't think of it as having two ways to do the same thing, they are really two separate things:

1. If you want to configure the values and variants for a core plugin, you should do that using the variants and theme sections of your config file.

2. If you want to manually provide the configuration object for a core plugin, you can use the corePlugins section of the config as a sort of escape-hatch to bypass how Tailwind normally works and configure things by hand.

So while you can use 2 to do what you're supposed to do with 1, the purpose isn't really to give you two ways to do the same thing, it's just to give you an escape hatch if for whatever reason in the future it makes sense for people to directly configure a plugin. Think of the corePlugins key sort of like an advanced/voids-your-warranty sort of secret config.

[MichaelDeBoey]

@adamwathan If you look at it that way, it's indeed less confusing.
Still not 100% convinced, but that's probably because I haven't used it yet.

Thanks for taking your time Adam! 😉