Fix width of emoji ZWJ sequences with skin tone modifiers - #20108

Open in StackBlitz

yarn add https://pkg.pr.new/@prettier/plugin-hermes@20108.tgz

yarn add https://pkg.pr.new/@prettier/plugin-oxc@20108.tgz

yarn add https://pkg.pr.new/@prettier/plugin-yuku@20108.tgz

yarn add https://pkg.pr.new/prettier@20108.tgz

commit: 4c71ae2

✅ Deploy Preview for prettier ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	4c71ae2
🔍 Latest deploy log	https://app.netlify.com/projects/prettier/deploys/6aade93d1f0dd1000827823a
😎 Deploy Preview	https://deploy-preview-20108--prettier.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

The Node.js 18 job fails the same way on other open PRs, for example #20107 and #20103, so it is not caused by this change.

Should it be fixed on emoji-regex side?

No. emoji-regex follows the Unicode RGI set, and 👨🏻‍👩🏻‍👧🏻‍👦🏻 is not in it. V8 agrees — /\p{RGI_Emoji}/v splits that string into the same four matches:

"👨🏻‍👩🏻‍👧🏻‍👦🏻".match(/\p{RGI_Emoji}/gv)
// [ '👨🏻', '👩🏻', '👧🏻', '👦🏻' ]
"👨‍👩‍👧‍👦".match(/\p{RGI_Emoji}/gv)
// [ '👨‍👩‍👧‍👦' ]

Family sequences with skin tone modifiers were never added to RGI, unlike handshake or holding-hands. Asking emoji-regex to match them means matching non-RGI sequences, which drops the determinism the package promises.

The emojiRegex().test(...) check in the issue is misleading. test is true for any substring match, so it passes on the first part alone.

We need display width per grapheme cluster, not RGI membership. Intl.Segmenter reports one cluster here, so the join belongs on our side. The file already has a TODO to move to Intl.Segmenter — I can do that instead if you prefer.

I'll wait for mathiasbynens/emoji-regex#122

The file already has a TODO to move to Intl.Segmenter — I can do that instead if you prefer.

Can't do it since we support Node.js v14

Right, Node 14 rules out Intl.Segmenter. I'll keep the regex workaround in get-string-width.js as is.