Handle I18n case

[VincentLanglet]

PR checklist

• Addresses an existing issue: [Interface-name] Never prefix return error for I18nInterface #4476
• New feature, bugfix, or enhancement
• Includes tests
• Documentation update

Overview of change:

Interface name (never-prefix) doesn't return error for I18nSomething

CHANGELOG.md entry:

[bugfix] interface-name now handles interface starting with "I18n" correctly

[reduckted]

Instead of adding a special case just for "I18n", would a better solution be to check if the name without the "I" is a valid identifier? "18nFactory" isn't a valid identifier because it starts with a number, so the "I" prefix must be allowed.

This, of course, wouldn't work for "IDB", though I'm not sure why that was added as a hard-coded special case in the first place.

[VincentLanglet]

@reduckted It seems to hard to check what is a valid identifier.

I cant say every number are not valid identifier, because 3rdParty, 1rstItem, 2ndElement can be.

[reduckted]

I cant say every number are not valid identifier, because 3rdParty, 1rstItem, 2ndElement can be.

None of those are valid identifiers.

In JavaScript, identifiers can contain only alphanumeric characters (or "$" or "_"), and may not start with a digit.
- Identifier, MDN

So, what is allowed in an identifier name?

An identifier must start with $, _, or any character in the Unicode categories “Uppercase letter (Lu)”, “Lowercase letter (Ll)”, “Titlecase letter (Lt)”, “Modifier letter (Lm)”, “Other letter (Lo)”, or “Letter number (Nl)”.
- Valid JavaScript variable names in ES5

[VincentLanglet]

@reduckted Ok, need to do a regex so.

BTW, IDB was added as a short cup for IndexedDataBase, i think.
It's debatable but I'll keep it to not create regression/breaking change.

[JoshuaKGoldberg]

/cc @adidahiya, from the linked issue.

[adidahiya]

Yeah, I agree the existing hard-coded "IDB" special case is weird, but we should keep it around to avoid regressions.

would a better solution be to check if the name without the "I" is a valid identifier?

sounds good to me

[VincentLanglet]

After some reflexion, I'm not sure it's a good idea to check name.substr(1) is a valid identifier to know if name has a I prefix.

IDB case can be leggit. You don't want to forbid acronym. This way :

• Two letters words may be allowed : ID can be acronym for IndexedData.
• Three letters (+) words starting by two uppercases should be allowed if the third letters is also an uppercase. Like IDB or IDKWhatIsThis. We should also allow ID42, ID_42 or ID$42.

A good rule seems to be :
hasPrefixI: name[0] = 'I', name[1] Uppercase, name[2] Lowercase

And best way to check if name[1] is uppercase (and avoid special numeric or _, $ cases) is to check that name[1] is not lowercase. In the same way, I check name[2] is not uppercase.

[adidahiya]

can you add some test cases in always-prefix/test.ts.lint as well? I feel like this will affect that option's behavior.

with always-prefix, I think the behavior should be:

• failures: ID
• valid: IDB (or, any all-caps interface name starting with I)

I know it feels a little silly since these are edge cases in naming, but we should try to be consistent in some way

[VincentLanglet]

I can add test yes.
But I didn't change the behaviour for the always-prefix rule.

Actually the test check only if the first letter is I.
Now I'm thinking about it, an interface called Information should return an error but it doesn't.

With always-prefix, I think ID should return no error.
You can create an A interface, called IA with prefix. The same way a D interface would be named ID with prefix.

To be consistent the best way is to check
always-prefix && !hasPrefixI && !EdgeCase or never-prefix && hasPrefixI
Where EdgeCase are two letters upercase interface starting by I.

[VincentLanglet]

@adidahiya @JoshuaKGoldberg I added a lot of test and then fix the edge cases.

[styu]

I think this change caused a regression, I'm noticing now that correctly prefixed interfaces that have a number in it (e.g. IS3Foobar) is now returning errors

[VincentLanglet]

@styu I already made a fix here #4626, I'll check it fix your case

[styu]

thanks so much!