npm tailwindcss 1.9.3

latest releases: 4.0.0-alpha.14, 4.0.0-alpha.13, 4.0.0-alpha.12...
3 years ago
  • Fix issue where tailwindcss init --full scaffolded a corrupt config file (#2556)
  • Remove console warnings about upcoming breaking changes (see note below)

I've opted to remove the console notices about upcoming breaking changes (that encouraged users to opt-in to future features using the future option in their config file.)

While I had good intentions for this approach originally, I'm realizing now that it just ends up creating more confusion and a sloppier documentation story. Any breaking changes can't really be documented easily because the documentation needs to show the stable version of any given feature, since we can't assume someone has opted in to the new stuff.

This means that when someone does opt in, they are basically opting in to being out of sync with the documentation, which is a crappy experience for them, especially if they can't upgrade to Tailwind 2.0 in the near future because they need to support IE11.

For this reason I've decided to stop warning about the upcoming breaking changes so that we don't force users to opt-in to an essentially undocumented version of the framework. Instead we will continue to maintain the "upcoming changes" page in the docs, and continue to ship new ideas behind flags for people to test but without the nudge to upgrade. Folks who are comfortable opting-in to the new stuff early can do so, and folks that aren't can comfortably keep using things the way they are (along with complete documentation) and upgrade to the next version all at once, like people have done traditionally with most dependencies.

I will always strive to make breaking changes as painless and minimal as possible, so spending an hour to do the upgrade in one sitting is never going to be too bad. I highly value backwards compatibility and will never make needlessly breaking changes. An improvement is only worth making if it improves things enough to make up for the upgrade cost, and that's usually pretty rare. For example lh-5 might be a nicer class name than leading-5 but it is absolutely not worth breaking everyone's muscle memory and forcing them to replace hundreds of instances of classes in their projects. We'll only make breaking changes if they unlock meaningful new possibilities or fix fundamental problems that are holding people back.

Don't miss a new tailwindcss release

NewReleases is sending notifications on new releases.