feat: id-length counts graphemes instead of code units

[sosukesuzuki]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

Fixes #16316

Counts graphemes instead of code units with grapheme-splitter

Is there anything you'd like reviewers to focus on?

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	edab15b
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/6333270c26227b0008b2da85

[snitin315]

Can we cover more test cases here? Playground Link

var myObj = { 𐌘: 1 };

(𐌘) => { 𐌘 * 𐌘 };

class 𠮟 { }

class Foo { 𐌘() {} }

class Foo1 { #𐌘() {} }

class Foo2 { 𐌘 = 1 }

class Foo3 { #𐌘 = 1 }

function foo1(...𐌘) { }

function foo([𐌘]) { }

var [ 𐌘 ] = arr;

var { prop: [𐌘]} = {};

function foo({𐌘}) { }

var { 𐌘 } = {};

var { prop: 𐌘} = {};

({ prop: obj.𐌘 } = {});

[sosukesuzuki]

Thank you! 39928ab

[snitin315]

LGTM. Thank you!

I'll leave this open for others to review.

[nzakas]

The code looks good to me. Can you please also update the documentation to explain that this rule counts graphemes instead of characters?

[mdjermanovic]

The code looks good, but counting graphemes instead of code points / code units has a significant performance impact.

I enabled "id-length": "error" in our config, and ran eslint . with TIMING=all.

Before this change:

Rule                                          | Time (ms) | Relative
:---------------------------------------------|----------:|--------:
indent                                        |  5759.606 |    16.8%
jsdoc/check-access                            |  1141.858 |     3.3%
jsdoc/valid-types                             |  1065.092 |     3.1%
n/no-missing-require                          |   963.300 |     2.8%
n/no-extraneous-require                       |   942.378 |     2.8%
jsdoc/check-types                             |   892.590 |     2.6%
jsdoc/check-tag-names                         |   756.448 |     2.2%
n/no-unpublished-require                      |   710.689 |     2.1%
jsdoc/check-values                            |   660.609 |     1.9%
jsdoc/check-alignment                         |   637.052 |     1.9%
...
id-length                                     |    86.412 |     0.3%

After this change:

Rule                                          | Time (ms) | Relative
:---------------------------------------------|----------:|--------:
indent                                        |  5713.065 |    15.4%
id-length                                     |  3292.387 |     8.9%
jsdoc/check-access                            |  1136.082 |     3.1%
jsdoc/valid-types                             |  1037.168 |     2.8%
n/no-missing-require                          |   936.313 |     2.5%
n/no-extraneous-require                       |   920.256 |     2.5%
jsdoc/check-types                             |   843.173 |     2.3%
jsdoc/check-tag-names                         |   724.359 |     2.0%
n/no-unpublished-require                      |   706.890 |     1.9%
jsdoc/check-values                            |   631.021 |     1.7%

Maybe we should consider making this behavior optional?

[nzakas]

Nice catch! Maybe we could first check to see if there are actually any non-ASCII characters before applying the new behavior?

[sosukesuzuki]

Thanks for your comments about the performance! As @nzakas commented, I did an ASCII check first and used String length if it was ASCII. a6beb2e

The resulting performance was as follows:

Before this PR:

Rule                                          | Time (ms) | Relative
:---------------------------------------------|----------:|--------:
id-length                                     |    81.275 |     0.3%

After this PR:

Rule                                          | Time (ms) | Relative
:---------------------------------------------|----------:|--------:
id-length                                     |   145.700 |     0.5%

If this performance decrease is unacceptable, I think we should add an option.

[mdjermanovic]

Marked as feat because the change in counting can produce more warnings with the same configuration for this rule.

[nzakas]

LGTM. Just waiting for @mdjermanovic

[mdjermanovic]

A small suggestion to clarify the last two tests, then LGTM

[mdjermanovic]

LGTM, thanks for contributing!