Fix parallel variant ordering clash #9282
Conversation
It hasn’t been used in a while
It’s not perfect but it’s close
it adds a new bit so it can’t
dark mode class name
| @@ -107,7 +107,7 @@ test('variants without & or an at-rule are ignored', () => { | |||
|
|
|||
| test('arbitrary variants are sorted after other variants', () => { | |||
| let config = { | |||
| content: [{ raw: html`<div class="[&>*]:underline underline lg:underline"></div>` }], | |||
| content: [{ raw: html`<div class="underline lg:underline [&>*]:underline"></div>` }], | |||
There was a problem hiding this comment.
I had an error in my terminal and fixed it and now GitHub Actions is complaining and I'm pretty sure the new code is the correct code. 🤔
Symlink and build instead of adding a recursive dev dependency It breaks node < 16
thecrypticace
force-pushed
the
fix/parallel-variant-ordering-clash
branch
from
4215841
to
7c121a5
Compare
# Conflicts: # CHANGELOG.md
|
Changing the order of generated classes affects precedence. Why is this not a breaking change? |
|
@AndyOGo are you running into actual issues? The ordering changes we did shouldn't result in any breaking change unless you were already relying on behaviour that was non-deterministic before and could break the moment you introduced a new content file. A more detailed comment can be found here: #10603 (comment) If you are running into issues, then could you open an issue with a minimal reproduction repo attached so that we can take a look? |
|
Thanks for your quick reply and sharing that comment @RobinMalfait I look at it from a CSS spec and semantic versioning viewpoint. |
Our ordering for parallel variants could result in some non-deterministic behavior depending on which ones you used and how many utilities were registered before that utility that was using the parallel variant.
This was a side effect of the single bigint sorting scheme we used. We've replaced it with Objects that have a better breakdown of what each section represents. This also means that the bigint numbers we're working with are now MUCH smaller. And, generally, only have to use large numbers for the bitfield used for variants.
This should also result in a minor speedup for the implementation of
getClassOrder