📎 Implement `useConsistentStringFunctions` - unicorn `prefer-string-trim-start-end` `prefer-string-slice`

[minht11]

Description

Implement unicorn/prefer-string-trim-start-end and unicorn/prefer-string-slice

The rules themeselves are straightforward, and naming useConsistentStringFunctions fits them, question I have should this rule include other string related operation rules such as prefer-string-replace-all and prefer-string-starts-ends-with if yes is the current name appropriate?

Will work on this rule.

[chansuke]

Can I pick this issue?

[minht11]

@chansuke I have started implementing it, but haven't worked on it for a while so sure why not. One insight I can provide, that substring and slice are not identical unicorn/prefer-string-slice provides a lot of complex fixes which require type inference or static analysis which biome does not support yet. For Biome lets provide simple fixes and in other cases diagnostic error is good enough.

[Conaclos]

ne insight I can provide, that substring and slice are not identical

Because of this we should certainly create a dedicate rule for unicorn/prefer-string-slice?

[minht11]

If we are only including unicorn/prefer-string-trim-start-end and unicorn/prefer-string-slice under useConsistentStringFunctions I think it's fine to keep them together, documentation wise it wouldn't be that hard to explain, link to MDN section about differences slice/substring would be enough in my opinion. And of course note about it in the rule diagnostic.

From implementation standpoint detection is not hard, fixes requiring type inferences are, but we don't need to implement them right now (if at all?), so it's fine.

The only case I see that maybe some users would like to disable substring part, I feel that is unlikely, but in that case we could provide an option.

Because of that I lean towards keeping them together.

[Conaclos]

Because of that I lean towards keeping them together.

Looks fair to me.

[minht11]

Based on discussion on #3039 (comment) this rule should be split into two separate ones. To allow easier implementation, documentation and being more consistent with other rules. Sorry for the trouble @chansuke

[chansuke]

@minht11
No problem.
Thank for your information.

[chansuke]

Should it be:

• useStringTrimStartEndMethod
• useStringSliceMethod

? Thanks.

@minht11 @ematipico @Conaclos

[Conaclos]

Should it be:

useStringTrimStartEndMethod
useStringSliceMethod

The unicorn rules don't retrieve type information. So, these rules apply to all methods named trimLeft, trimRight, substring, and substr. In this respect, we could call these rules:

• noTrimLeftRight
• noSubstr

Note that I use the negation form here because I think it is more appropriate and consistent with our existing rules.

In the future we might decide to introduce new rules that make use of type information. These rules could be called noStringTrimLeftRight and noStringSubstr.

I didn't add the Methods suffix because we have similar rules without this suffix, notably useFlatMap, noFlatMapIdentity, and noForEach. I am not opposed to add the suffix. My only concern is consistency. Any opinion?