Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates all of our PostCSS-related dependencies to the latest version, since I guess that's something we should occasionally do :)
Although most dependencies have been updated to a new major version, none of the breaking changes there really impact Tailwind except for one, which is
postcss-selector-parser
.Prior to using the latest version of
postcss-selector-parser
, Tailwind has taken ownership of and responsibility for all escaping that needs to happen when using non-standard characters in class names, like we do withsm:text-blue
(.sm\:text-blue
) orw-1/4
(.w-1\/4
).Now,
postcss-selector-parser
tries to intelligently handle all escaping on our behalf (which is awesome!). However, in trying to push that work out topostcss-selector-parser
, I discovered that it escapes:
differently than we do (it uses the unicode codepoint\3A
), which when combined with this bug in css-loader causes all of Tailwind's classes that use colons to break when using webpack.The underlying library causing the escaping to be handled differently is cssesc, which escapes colons that way to preserve compatibility with very old versions of IE.
Although this isn't really their problem (the bug is in css-loader), I've opened an issue on cssesc asking if they would consider dropping support for IE < 8, as that would fix this problem for our use case:
mathiasbynens/cssesc#18
For now, I am using a special API available in
postcss-selector-parser
that lets us bypass their escaping so we can still do it by hand. This is a big disappointment as I'm sure my implementation is incredibly naive and not remotely as robust, but it keeps things working at least as well as they worked before.Updating and accommodating these dependencies fixes #613 as well, which I will add a failing test for shortly.
I am going to have to think very hard to figure out if there are other consequences to this update (likely in the plugin system if anywhere, and probably with the modifySelectors helper), so will work that out before including this in a release.