feat(core,preset-mini)!: change pseudo sort and add no-merge

[chu121su12]

To match tailwind's behavior as mentioned in #2416, unocss need to not merge the css output. The noMerge flag in generate() is non-breaking, but it may not be enough to address the issue. The second changes--which maybe breaking--is in the preset-mini, with altering pseudoModifier behavior, such that:

• all pseudo now have sort meta set
• the pseudo is ordered such that:
  • raw rule < fn pseudo (+10 sort) < normal pseudo (+30) < tagged (peer, group, etc; +50)
  • the order of :active is still ahead of each modifier above (+10 each)
    This ordering (by itself) should not change how the css are generated since it will just change the order where they appear inside the comma separated selectors. But with the changes in sort value, it is a just in case breaking scenario just to be safe.

The order of fn pseudo vs normal pseudo may be too much of a change, but if you really need to change the sort order, you may opt in to the uno-layer-x variant for better sort control.

In short, previously:

/* layer: default */
.focus\:top-0:focus,
.top-0{top:0;}

after, with global noMerge:

/* layer: default */
.top-0{top:0;}
.focus\:top-0:focus{top:0;}

[netlify]

✅ Deploy Preview for unocss canceled.

Built without sensitive environment variables

Name	Link
🔨 Latest commit	cf418ee
🔍 Latest deploy log	https://app.netlify.com/sites/unocss/deploys/64292d5ec7bb0600084d5907

[sibbng]

I addressed some related issues in #1973. But that noMerge option on the generate function seems unnecessary since we already have the mergeSelectors option in the config. And this approach doesn't fix the issue on userland since generate option is supposed to be used by lib authors.

In my opinion disabling merge shouldn't change the order of the rules. This sounds like a side effect.

Merging is useful when users have classes like w4 and w-4 in their code. But when it comes to pseudos, we shouldn't merge them with raw utilities to keep their specificity consistent.