Simpler support for responsive components and style layers

[adamwathan]

This PR is an alternate approach to what was presented in #2025.

This PR adds first-class support for variants for "component" styles. It differs from #2025 in the following ways:

Component and utility responsive styles are intermingled

Rather than inserting all responsive component styles, then all responsive utility styles, this PR groups them together by screen size.

So the general order in the CSS is this:

• Base component styles
• Base utility styles
• sm component styles
• sm utility styles
• md component styles
• md utility styles
• lg component styles
• lg utility styles
• xl component styles
• xl utility styles

This leads to more intuitive results when combining components and utilities at various breakpoints.

No @screens components/utilities directives

Because of the change explained above, there is no need to introduce @screens components/utilities. Instead, we are keeping @tailwind screens, since all responsive styles are now zipped together per screen size, no matter what layer (components/utilities) they belong to.

No @responsive components { ... } syntax

The argument for the @responsive at-rule has been removed. Now any responsive variants generated using the addComponents API are just automatically categorized as components, so this doesn't need to be done explicitly.

No support for children in @tailwind directives

Support for things like this have been removed:

@tailwind components {
  .btn { ... }
}

While I think this is still a useful idea at a high level, this implementation had the problem of not allowing you to split your styles into multiple files, because this is invalid syntax using postcss-import:

@tailwind components {
  @import './components/button';
}

New @layer directive has been added

A new @layer directive has been introduced as a better solution to nesting children within @tailwind components { ... }.

It looks like this:

@layer components {
  .btn { ... }
}

This lets you "bucket" your custom styles into the right "layer" (term comes from ITCSS) so Tailwind can mark them appropriately and purge them properly based on your purge mode configuration.

You can nest @variants and @responsive directives within @layer directives to make sure all generated variants are also categorized correctly:

@layer components {
  @responsive {
    .prose { ... }
  }
}

I probably won't document this for a while because it's more of an implementation detail than a feature, but this is how you'd properly bucket things in custom CSS if you aren't using the plugin system instead.

Risks

I don't think there's any real issues here — there were some tricky internal tweaks necessary to get everything working but all of the tests are passing so things seem good. The closest thing to an alarm-sounding issue I ran into was that for a minute @apply stopped working because every generated Tailwind style was nested under a @layer, and @apply doesn't support applying classes that are nested under another rule. Flattening the layers to control comments before substituting @apply at-rules was enough to fix it, but does make me slightly nervous there could be other similar types of issues that crop up.

Nevertheless I feel very confident in our test suite, so since everything is passing I would be very surprised if we ran into an issue that wasn't solvable.

This fixes an important issue in the Tailwind Typography plugin so I'd like to get this merged and released as v1.5 (sadly a waste of a good version number) today pending any problems anyone points out 👍