[Replacement]: eastasianwidth

[tats-u]

Package to replace

eastasianwidth

Suggested replacement(s)

• get-east-asian-width
• (meaw)

If you're using it solely to get the terminal character width:

• string-width
• fast-string-width
• Bun.stringWidth (Bun dedicated)

Manifest type

preferred (lighter or more modern alternative package)

Rationale

eastasianwidth has not been updated for a long time and is not based on the latest Unicode version.

get-east-asian-width is regularly synced with the latest Unicode version in minor releases like Node.js and much more popular than meaw.
meaw introduces major version bump when syncing with Unicode versions so is less recommended.

If you're using it solely to get the terminal character width, string-width-like packages are preferred because they can handle grapheme clusters composed of more than one characters.

Availability

No response

Code example (optional)

[43081j]

both are probably redundant in most cases and can be replaced by fast-string-width, since almost all consumers are using this to calculate terminal visual width.

im not sure i'd suggest get-east-asian-width, i'd probably suggest fast-string-width.

do you happen to know any usages in popular packages that specifically need to know its the east asian width (and not just the visual string width)?

[gameroman]

eastasianwidth and get-east-asian-width are basically used only by 3 packages

[43081j]

yep, string-width in the latter - which should be replaced by fast-string-width.

we could add them to the manifest but they'd basically point to fast-string-width like string-width does.

thoughts? also happy to close and just rely on people removing string-width directly

[tats-u]

After quickly reviewing the code for fast-string-truncated-width, I felt its design to be not so great. It's a high-maintenance design that struggles to keep pace with Unicode's annual version updates.
At its core, libraries handling East Asian Width can also be used as one component for determining whether a given character is CJK. These types of libraries serve purposes beyond just estimating terminal character widths.

[tats-u]

are basically used only by 3 packages

Why are you deliberately ignoring the long tails (many niche packages)?

[tats-u]

I felt its design to be not so great. It's a high-maintenance design that struggles to keep pace with Unicode's annual version updates.

e.g. It cannot immediately accommodate newly added East Asian scripts (e.g., Khitan script in Unicode 13).

https://codepoints.net/U+18B00

EAW→W / string-width→2 / fast-string-width→1

This example above is quite a corner case though.

[gameroman]

I've just tested and it returns 2 for me

import width from 'fast-string-width'

width('\u18B00') // 2

Unless I misunderstood

[tats-u]

> console.log(Iterator.from('\u18B00').map(c => `${c} (U+${c.codePointAt(0).toString(16).toUpperCase().padStart(4, '0')})`).toArray().join("\n"))
ᢰ (U+18B0)
0 (U+0030)
undefined
> console.log(Iterator.from('\u{18B00}').map(c => `${c} (U+${c.codePointAt(0).toString(16).toUpperCase().padStart(4, '0')})`).toArray().join("\n"))
𘬀 (U+18B00)

[gameroman]

Oh yeah, sorry, you're right 👍

[43081j]

It's a high-maintenance design that struggles to keep pace with Unicode's annual version updates

can you explain more? the reason fast-string-width is smaller is because it doesn't need to hand roll a unicode table.

it basically depends on the engine's RegExp classes and some additional ranges instead. The way string-width and its child packages work is the "old way" of doing it from before RegExp had it built in.

most likely one of the ranges just needs expanding, which is equal or less effort to someone manually hand rolling a huge unicode -> width table (old way).