New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow users to override a core plugin's configuration #644

Merged
merged 7 commits into from Feb 5, 2019

Conversation

Projects
None yet
2 participants
@adamwathan
Copy link
Member

adamwathan commented Feb 5, 2019

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.

@adamwathan adamwathan merged commit a485400 into next Feb 5, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@adamwathan adamwathan deleted the configure-plugins branch Feb 5, 2019

@MichaelDeBoey

This comment has been minimized.

Copy link
Contributor

MichaelDeBoey commented Feb 6, 2019

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

@adamwathan

This comment has been minimized.

Copy link
Member Author

adamwathan commented Feb 6, 2019

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

This comment has been minimized.

Copy link
Contributor

MichaelDeBoey commented Feb 7, 2019

@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

This comment has been minimized.

Copy link
Member Author

adamwathan commented Feb 7, 2019

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

This comment has been minimized.

Copy link
Contributor

MichaelDeBoey commented Feb 8, 2019

@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! 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment