Bug: prefer-spread shouldn't encourage iterating over strings

[JoshuaKGoldberg]

prefer-spread reports on String#split(''), fixing to a typical .... That matches the design of string iterability as it was originally intended. However, allowing primitives to be iterated over is widely considered a mistake: https://github.com/tc39/how-we-work/blob/main/normative-conventions.md#reject-primitives-in-iterable-taking-positions.

Proposal: can eslint-plugin-unicorn remove the preference of String#split('') from prefer-spread?

const text = 'hello 👋';

text.split(''); // "fixed" to [...text]

I'm roughly quoting @Josh-Cena from this discussion: https://github.com/typescript-eslint/typescript-eslint/pull/8509/files#r1781707713. Context: in typescript-eslint, we're implementing typescript-eslint/typescript-eslint#748 Rule proposal: prevent array, iterable and function spreads into objects. The rule is set to report on ...string by default... and then unicorn/prefer-spread reports on String#split(''). You can't win!

[Josh-Cena]

I do appreciate that this is a virtually impossible task to be done correctly by default. .split("") is wrong but so is ..., just on different levels. JS should really expose iterator getters like .graphemes(), .graphemeClusters(), etc... But for now, either removing the suggestion or recommending Intl.Segmenter makes more sense. Alternatively, in our rule, we can add docs for disabling checking string spreading.

[fregante]

I'll bring in the quote from the linked tc39 document:

it is now considered a mistake to iterate a String without specifying whether the String is providing an abstraction over code units, code points, grapheme clusters, or something else.

This makes sense but the intent of the rule here is to push people to use a better segmenter. I think that in most cases you do want [...string] over string.split(''); the latter is probably only needed in low-level code. For this reason I still think that .split('') is generally wrong and the solution here is still preferable. People who do know the difference can disable the rule locally or globally.

Alternatively, is this the correct solution?

- 'hello 🎅🏻'.split('')
+ [...new Intl.Segmenter().segment('hello 🎅🏻')].map(s => s.segment);

[Josh-Cena]

Alternatively, is this the correct solution?

I believe so. I'm not sure if grapheme splitting is ever locale-sensitive but the general form looks fine.

[JoshuaKGoldberg]

Yeah 😕 it's not great how there isn't a single good canonical solution. I think we have a collection of "this might not be right" reports, but no single autofix/suggestion to pair them with.