Upgrade string-width

[adam2k]

Related to chalk/ansi-regex@8d1d7cd

Additional information CWE-400 https://cwe.mitre.org/data/definitions/400.html

[adam2k]

@bcoe or @substack can I get maintainer approval to run workflows? I haven't contributed to this repo yet, so let me know if there is some other way I should request access. Thanks!

[ljharb]

Noting: string-width v5 requires node 12 while v4 requires node 8, luckily this isn't a breaking change for yargs since it already requires node 12.

However, string-width v5 is ESM-only, which means it can't be required, which means yargs likely can't use it.

I'd suggest finding an alternative dependency that isn't ESM-only and also lacks the CVE.

[bcoe]

@ljharb @adam2k the ESM version of yargs already dropped using string-width, ironically because at the time string-width wasn't ESM.

The alternate implementation is here.

I suggest we just switch to this approach for both ESM and CJS, the downside is that string width will be slightly off for some unicode characters I believe (am I correct in my understanding that some unicode characters are two ascii characters wide?).

Either way, I think this is a minor regression, and worth dropping a dep.

[ljharb]

@bcoe that alternate implementation is quite wrong for many things - the spread operator only splits to code points, but many emojis are multiple code points - '🏳️‍🌈' for example, has a length of 6 and contains 4 code points.

A proper replacement would likely require using Intl.Segmenter and splitting by grapheme clusters, and then checking the resulting array length.

[woehr]

The path of least resistance here would probably be to see whether strip-ansi will backport a dependency bump to address the CVE and then to get string-width 4.2.2 to update the strip-ansi dependency. I've asked whether strip-ansi can do a hotfix here: chalk/strip-ansi#40.

[bcoe]

@Qix- kindly back-ported a fix to ansi-regex@5.0.1, so we should be good now 👍

chalk/ansi-regex#38