Add support for setting screens in JS config

[philipp-spiess]

This PR adds support for the simple case of the screens option inside JS config paths. This allows JS configs to extend the responsive theme by adding custom breakpoints. Here's an example from our v3 docs:

{
  theme: {
    screens: {
      'sm': '640px',
      // => @media (min-width: 640px) { ... }

      'md': '768px',
      // => @media (min-width: 768px) { ... }

      'lg': '1024px',
      // => @media (min-width: 1024px) { ... }

      'xl': '1280px',
      // => @media (min-width: 1280px) { ... }

      '2xl': '1536px',
      // => @media (min-width: 1536px) { ... }
    }
  }
}

For simple breakpoints, this will extend the core breakpoints and will work with the min-* and max-* utilities. However, we also support complex ways of setting up custom screens like this:

{
  theme: {
    extend: {
      screens: {
        sm: { max: '639px' },
        md: [
          { min: '668px', max: '767px' },
          { min: '868px' },
        ],
        lg: { min: '868px' },
        xl: { min: '1024px', max: '1279px' },
        tall: { raw: '(min-height: 800px)' },
      },
    },
  },
}

For these complex setups, we only generate the shorthand variant (e.g. tall) but those won't integrate within min-* and max-*. In v3, adding any of these complex configurations would omit any min-* and max-* variants.

[thecrypticace]

Is it possible for us to do this all at one time at the end rather than after every inserted variant?

We're definitely doing more traversals and object replacements than we need to but if it proves to be too complex then this is fine for now.

[philipp-spiess]

We have to do it once for every utility that is inserted this way. Each one will handed their own order. I do need a test for this since I think it might now be adding it in inverse insertion order.

[thecrypticace]

Yeah it would make sense that this is the reason some things are going being inserted in reverse order. I was thinking of something like this:

• Get a list of all the variants after min (and their compare fns)
• Insert our appropriate screens into the min group
• Insert other screens after the min group
• Move the previously recorded variants past the last variant we just inserted (only if there is one)

I think this would work but I'm not sure if the separate compareFn map complicates that.

[philipp-spiess]

Hm I’m not sure I follow, I think we can keep doing what we do right now but only loop over the variants in reverse order, this way we:

• Still insert appropriate screens into the min group. For that, the order does not matter since it'll use the compare function
• Insert complex variants after the min group. But since we loop in reverse order, we will will always move the previously inserted complex variant down.

I pushed a commit that changes this and it fixes the order.

fixed