remove @typescript-eslint/interface-name-prefix from recommended

[aladdin-add]

consider removing @typescript-eslint/interface-name-prefix from recommended, since it seems just a stylistic issue.

Versions

package	version
@typescript-eslint/eslint-plugin	1.5.0

[bradzacher]

The recommended that has been setup is based off a number of things, namely (in this case) what is done in the official typescript documentation/codebase.

The reason this is recommended as never adding a prefix is because prefixing your interface names (esp with I) is generally considered an antipattern in TypeScript.

People generally fall into this pattern because they have come from languages like C#/Java where the convention is to prefix interface names with I to differentiate them from concrete implementations (why exactly is a whole other discussion).

In TS there's no technical reason you need to differentiate the naming of types, interfaces, classes, functions and vars.

That being said, if there is drive from the community, we can remove it.

[aladdin-add]

agreed to keep it! just bring it up since I was start using it in an existing repo.

maybe the docs can be improved(as you described).

It can be hard to differentiate between classes and interfaces. Prefixing interfaces with "I" can help telling them apart at a glance.

[bradzacher]

We can definitely add something to the docs!

For those that are giving my comment a 👎 (and the OP a 👍) - please let me know your use case for specifically giving interfaces an I prefix.
I'm yet to hear a good argument for it that isn't just "it's what I'm used to".

I don't see any reason to specifically prefix interfaces when the following two blocks are both valid TS and result in the same functionality:

interface Foo {
  prop: string
}

// the same
type TypeBar = Foo & {
  prop2: number
};
interface InterfaceBar extends Foo {
  prop2: number
}

type Foo = {
  prop: string
}

// the same
type TypeBar = Foo & {
  prop2: number
};
interface InterfaceBar extends Foo {
  prop2: number
}

Considering more or less type == interface, why would you differentiate types from interfaces?

[rstrom]

We prefix with I in order to differentiate from components, generated graphql types etc. and to make importing easier (not to differentiate types vs. interfaces per se). Personally I hate having such an arbitrary naming rule but it is helpful for our team.

It would be great to have a better solution at the language / packaging level since it is always ambiguous when you import ComponentName from a package whether that is a type / interface or something else. Or maybe I am missing something and someone has a simpler approach here?

[ThomasdenH]

My main issue with the rule is the inherent problem of false positives. An otherwise perfect codebase will still be linted if it contains types like interface IBAN {}. I'd argue that having this rule enabled by default doesn't have much benefit compared to this extra effort.

[bradzacher]

@ThomasdenH False positives like that are a bug, and are easily fixed in the rule's regex match.
We never added a case for all-caps names.

---

@rstrom
The bigger question I have from your comment: why are there so many exported type names which collide within your codebase?
Is it because you have component names that match your graphql type names?

The general (and much clearer solution) I've seen for that problem is not to use named imports, instead doing the following: import * as Types from 'my/generated/types'. Types have no concept of tree shaking, so there's no real advantage to specifically naming your imports AFAIK.

This leads to a better convention than just I prefixing because it's more resistant to collisions:

import * as GQL from 'my/generated/types';
import { Entity, IEntity } from './component';

// GQL.Entity can never collide with Entity
// GQL.Entity can never collide with IEntity
// always clear which entity I want as I establish the convention that I've "namespaced" the graphql types


// versus


import { IEntity } from 'my/generated/types/I';
import { Entity, IEntity } from './component';

// because you've only prefixed it with an I, you don't know which IEntity to use and when.
// no namespacing so hard to tell which is which and in what case to use which one..

It's pretty trivial to write an internal eslint rule to enforce always using * as GQL when importing from your graphql type file(s), enforcing a better naming convention across your code.

---

It would be great to have a better solution at the language / packaging level since it is always ambiguous when you import ComponentName from a package whether that is a type / interface or something else.

There is no way to differentiate between them at code-time, no. Flow uses the type keyword to differentiate type import/exports, but typescript doesn't discriminate. It does discriminate in compile-time usages though: you can't use types in value context, and (for the most part) you can't use value types within type context (the exceptions being classes and enums).

// foo.js
export const num = 1;
export default class Foo {};
export type Bar = {| prop: string |};

// file.js
import type { Bar } from './foo.js'
import Foo, { num } from './foo.js'

[rstrom]

Thanks @bradzacher that's a good idea!

One drawback with that approach is that the existing integration with an IDE like VS Code... If you start typing IEntity in VS Code you can import it right away, without having to remember which subdirectory it's in (and avoids a collision between "Types" or "GQL" from separate directories). That argues for a better a solution at the editor-level, though, and I personally would prefer the syntactic feel of typing GQL.Entity over IEntity which feels ugly tbh.

[ThomasdenH]

@bradzacher What I meant by my comment is that it's inherently impossible to know whether the starting 'I' is part of the name or not. The name IEntity could signify an interface Entity with a useless prefix or the 'I' could actually stand for something (for example 'Internet' or 'International'). In fact, I don't know if there is an example that is unambiguously using an 'I' as an interface prefix.

You might argue that starting with a single capital is not idiomatic anyway, but then the scope of the rule changes a lot. To be consistent other capitals would need to be caught as well.

So if a perfect codebase might require error surpressions for the rule, I'd argue against having it in the default rule set.

[bradzacher]

I see your point, though I would argue that is quite an edge case that can be fixed by using a better, clearer naming convention.
Single character abbreviations mostly went "out of style" as powerful IDEs came into being.
No longer do you have to manually type out a variable name, as the IDE can autocomplete for you, so there's no real reason to shorten anything unless you're trying to make your code "look nice".

The general use case is this: if you're writing interfaces that start with a capital I followed by a second capital letter, then you're following the anti-pattern of using I-prefixed interface names.

If you, as a user, know that your project uses shorthands that mean it's legitimate for your interface names to start with I, then it is up to you to disable the rule - using the recommended set doesn't preclude you from turning off rules that don't make sense for your specific project.

[s-h-a-d-o-w]

However this discussion will be resolved, I would still recommend to remove this line from the README:

TypeScript suggests never prefixing interfaces with "I".

Simply because on the very page you link to, they write twice that:

This is NOT a prescriptive guideline for the TypeScript community

Speaking about which - @bradzacher would you mind linking to some sources where it is said that this is anti-pattern and why? (I respect your arguments but you mentioned this right in the beginning already, so I assume it's not just you who makes them)

[jaredparkinson]

microsoft/TypeScript-Handbook#121

https://stackoverflow.com/questions/31876947/confused-about-the-interface-and-class-coding-guidelines-for-typescript/41967120#41967120

[awerlang]

I'd suggest to make it a warning instead an error. Or even creating another plugin with only stricter rules (I based off recommended but disabled a lot of them).

[lukescott]

IMO, the I recommendation should be removed. It's a hold-over from other languages, and does not apply to TypeScript. The style guide for TypeScript says:

Do not use "I" as a prefix for interface names.

Granted that style guide is intended for internal use within the Microsoft/TypeScript repo, but given the authors of TypeScript take the opposite stance, it probably shouldn't be default to require I.

I also very rarely see interfaces prefixed with I in the wild.

I'm not saying the default should take a stance either way - "always I vs never I". Neither should be an error/warning by default. Let the user apply the rule how they see fit.

[bradzacher]

Let the user apply the rule how they see fit.

This is not an argument for removal from the recommended set, as the entire point of the recommended set is to provide an opinionated default set of rules so that the user doesn't have to think about it.
Additionally - no matter what we choose for recommended value (off, warning or error), there is no extra effort required to configure based on taste:

{
  extends: ['plugin:@typescript-eslint/recommended'],
  rules: {
    '@typescript-eslint/interface-name-prefix': ['your-setting-here']
  }
}

---

Our recommended set is based off of typescript best practices, and the best practice (as you and others have stated) is to not prefix with I.
This is how we've designed the recommended set - best practices combined with existing community configs.

[bradzacher]

If people can provide a concrete argument as to why it should not be recommended, or if there is significant drive from the community, we're happy to remove it. Right now we have the following reasons:

• it's a stylistic rule, and stylistic rules shouldn't be recommended.
  • an interesting point, though not one we necessarily agree with because our recommended set is "best practice" (i.e. including stylistic changes).
• my project uses I prefixed interfaces.
  • good to know, but not a good argument for its removal.

[lukescott]

I would go by what Microsoft themselves do and what is mostly seen in the wild. I've seen perhaps one package out the many I've used, zero with what our company currently uses.

With that said, it might be easy to say "well then the recommendation should be never I". The problem is "always I" has been the recommendation for a signifiant amount of time. I think a lot of people override this, but others may stick with it in their private projects. So with that in mind, I would say it would be better to be neutral and don't require or disallow it.

I see recommended more as "sane defaults" that you can build on. I shouldn't need to override a bunch of rules. Instead, I should be adding to the rules that are not currently in recommended.

[bradzacher]

I think a lot of people override this

I'd love to know if people do, as that would be a good case to remove it from the recommended.
However, right now there are 392,154 weekly downloads of this package.
We have concrete evidence that ~20 people override it, and about similar (if not more) of evidence that people don't override it.

Based on those numbers, we're a long way from concrete evidence that I'm looking for to justify it's removal (which involves a major version bump as it is a breaking change).

I see recommended more as "sane defaults"

As mentioned - our recommended is not just a minimal set, but is instead a set designed instead to enforce best practices. Users reach straight for the recommended set by default when installing a new plugin, and we want the "default" experience to be that set of best practices.
Certainly happy to add another config which is instead a set of "sane defaults" (if anyone want to submit a PR with it, feel free).

I shouldn't need to override a bunch of rules

The way I see it; if a project overrides a bunch of rules from our recommended set then either:

• the project doesn't follow best practices (i.e. there's nothing for us to change), or
• our best practices are wrong (i.e. we should change).

[lukescott]

14k results where interface-name was changed it to never-prefix:

https://github.com/search?q=%22interface-name+true+never-prefix%22+extension%3Ajson+filename%3Atslint.json&type=Code

10k results where interface-name is set to false:

https://github.com/search?q=%22interface-name+false%22+extension%3Ajson+filename%3Atslint.json&type=Code

25k results with recommended with no mention of interface-name:

https://github.com/search?q=%22recommended%22+NOT+%22interface-name%22+extension%3Ajson+filename%3Atslint.json&type=Code

1k results that set interface-name to always-prefix on purpose:

https://github.com/search?q=%22true+always-prefix%22+extension%3Ajson+filename%3Atslint.json&type=Code

From the above, 48% of don't consider this a best practice enough to change it on their own. 28% went as far as choosing never-prefix. 50% kept the default. 2% of those choosing always-prefix on purpose.

The search is not perfect. It also doesn't count Bitbucket, GitLab, etc. Or private projects.

Significantly more than 20 though.

[bradzacher]

Significantly more than 20 though.

My point with saying that is that people are arguing for its removal because "people don't agree with it" without any stats behind it. So I was pointing out that opinions are cool and great to have, but how are people actually using it - what are the data points behind it?

The requestors are trying to convince us to make/accept the change. But we're not going to be convinced without good arguments or data to back up the request, and we're not going to do the research on their behalf...

---

Thanks heaps for going and getting some data! Though the searches are tslint instead of eslint, it's a good starting point (as the two rules do the same thing).

Small correction to your "recommended with no interface-name" query: specifically searching for "tslint:recommended" dropped that number by half (I think due to the copy pasted comments I mentioned).
https://github.com/search?q=%22tslint%3Arecommended%22+NOT+%22interface-name%22+extension%3Ajson+filename%3Atslint.json&type=Code

So looking at it (note the numbers given are approximate because every refresh changes the total results by as much as 4k in either direction...).

Total results 40.9k.

• (1.9K) 4% of results specifically turn it on to always-prefix.
  • Of those 1.9k, 13% (263) use recommended as well.
• (14k) 34% of results use recommended without changing the setting (i.e. use the default of always-prefix.
• (11k) 26% of results specifically turn it on to never-prefix.
  • Of those 11k, 25% (2.8k) use recommended (i.e. override the default).
• (14k) 34% of results specifically turn it off.
  • Of those 14k, 92% (13k) use recommended (i.e. override the default).

Another thing to note is that these searches reveal around 41k results, but also according to github search, there are over 840k tslint.json files. So the searches are somehow revealing only 4% of the dataset.....

Ultimately I'm not sure how much stock to put into these results.
Github is really bad at code searching. It's a starting point for data, but it's not good data I think.

Looking at some of the results themselves, they're a bit dubious in terms of quality:

• there are a lot of forks of repos (i.e. doubling the count of results for their main repo)
• there are lot of "demo" / "example" repos with no real value in this discussion (i.e. repos someone has used a tutorial to create, or are clearly not real projects with single digit commit counts).
• there are a lot of repos which have a tslint config with just an extends field.
• there are a lot of repos which have the exact same comment block at the top, suggesting the config has been copied from somewhere.

  /*
  Using recommended community rules
   https://github.com/palantir/tslint/blob/master/src/configs/recommended.ts
  */

It's too hard to tell if the above skews the results in one way or another, regardless I don't trust the numbers are at all accurate.
I'm going to leave the results as an example though, there's no statistically significant majority for any choice.

• 34% of the data has the rule off
• 26% of the data has it on for never prefix.
• 38% of the data has it on for always prefix.

Could try and do an analysis of eslint users, but idk if it's worth the effort with github search being the way that it is..

[lukescott]

Even with a 41k dataset, 60% is rather significant, is it not? Even if it were 40%, I would consider that high enough to take a neutral stance. This is "tab vs space, semi vs no-semi, double quote vs single" territory.

[bradzacher]

The problem is that I have very low confidence in the quality of the data for the reasons I outlined above.
As mentioned, there were wild swings in the number of results returned per search refresh (same search could come back saying anywhere between 8k and 14k results), so the %ages are potentially off by 10% in any direction.

A big problem which destroys my confidence in the results is the number of "demo" / "example" repos I saw in the results, which I believe heavily skews the number of "recommended without changing the setting" results. It's invalid data because it's not actual use of tslint.

Those repos are something like: find webpage with some typescript tutorial, download the tutorial's code zip (which includes a tslint.json), follow along and make <10 commits to the repo, and then abandon the repo.

---

The data paints a picture, sure, but it's a low confidence one which I don't want to base any decisions off of in of itself.

Considering how low the volume of feedback is on github (12 👍's), my current stance is that it's not worth bumping for a breaking change.

[vincentcr]

@bradzacher I think the problem with this rule is that it was clearly created to break the habit, ingrained into C# and Java developers, of always prefixing interfaces. Specifically, it was targeted to Microsoft employees with a C# background, since this rue originates from the internal guidelines for Typescript.

Now that Typescript is being massively adopted by web developers, who for the most part don't have such backgrounds, to forbid it feels like an arbitrary artefact inherited from another ecosystem.

As you mentioned, it's true that it's not necessary to systematically prefix interfaces with I, since in many cases you don't need to explicitly implement interfaces. But prefixing is still useful in certain cases, when you need to export both the type and a concrete instance, like a class or object, that matches the type.

Of course one could come up with another naming scheme, but again this I interdiction feels magical and weird unless you have a C#/Java background.

[bradzacher]

But prefixing is still useful in certain cases

Why would you disable an entire rule across your codebase just because there are some edge cases where you might want it off?

Handling certain edge cases is exactly the reason that eslint has disable comments:

// more ergonomic naming of the reusable interface
// eslint-disable-next-line @typescript-eslint/interface-name-prefix
interface IMyFoo {}
class MyFoo implements IMyFoo {}

export { IMyFoo, MyFoo }

As a support example for this - you could make the same argument for the camelcase rule.
"I consume an API which gives me snake_case properties, meaning that in order to define types for the API I have to define a type with snake_case properties. Because of this, I should disable the camelcase property checker across my entire codebase so it doesn't check this one edge case"

OR

I can leave the lint rule on to enforce the style across my entire codebase, and add a disable comment for the one edge case:

// the API provides snake_case properties, which we can't change
/* eslint-disable @typescript-eslint/camelcase */
interface MyApiType {
  some_property: string;
}
/* eslint-enable @typescript-eslint/camelcase */

---

Another solution is to use a different, more explicit naming convention. As you said - the I prefix means absolutely nothing to someone not familiar with another language that relies upon that convention.

So you could just as easily use an explicit convention like:

interface MyFooInterface {}
class MyFoo implements MyFooInterface {}

export { MyFooInterface, MyFoo }

[hbroer]

You can't enforce Interface Suffix. You just can enforce I Prefix. The I convention is used in other languages too, like the roots of typescript: C#. And last but not least is writing Interface suffix over and over again bullshit if you can archive the same with an I prefix. Prefixing interfaces with an I should be recommend, even if 90% of the developers don't do that. >90% don't use typescript, so it should be recommend to not using it? (same for strict mode) ^^

[lukescott]

Prefixing interfaces with an I should be recommend

The authors of TypeScript put in their own style guide the opposite - Never prefix with I. The majority of the TypeScript community do not prefix with I. So it does not make sense to make it recommended when it isn't considered a best practice in the TypeScript community.

[hbroer]

So suffix with Interface is? You can't see the difference if something is an interface or a class. It sucks in code reviews if you can't see if someone use classes as dependency instead of the interface.

class Example {
    @inject(TYPE.MyService)
    readonly myService!: IMyService;
}

vs

class Example {
    @inject(TYPE.MyService)
    readonly myService!: MyService;
}

The most developers are using classes as hard coded dependency and use interfaces just for data objects. But that is not a good practice even if it is common.

[bradzacher]

@hbroer - I've established this in other threads (such as #433 (comment)), but there's little to no difference between type and interface.

Do you prefix your type definitions with I?
If not - why do you special case interfaces when for most use cases they're the same as types?

---

To me your example makes no sense - one character difference is not easy to see and I know that most reviewers would miss that in a review.
OTOH MyServiceInterface is super explicit and clear.

But you said that it sucks to write - well aren't you using an IDE with autocomplete, like vscode? Keystrokes is such a false argument now a days that developer tooling is getting so good with things like intellisense.

[hbroer]

i don't use type for objects. Interfaces are enforced.

I have autocomplete. It is faster if you just need to type IWha(tever) then Wha(tever) and need to use cursors to select the right. The first example it is much faster.

[bradzacher]

It is faster if you just need to type IWha(tever) then Wha(tever) and need to use cursors to select the right

This is where intellisense shines - typing WhaI will substring match and highlight the most relevant result, which in this case is the Interface suffix. So it's no faster to autocomplete IWhatever.

So ultimately it's no faster to type when using developer tooling, and the name IThing (whilst being very concise) is significantly less clear than ThingInterface, meaning it's significantly harder to notice in code reviews (which was one of your original arguments).

You can't enforce Interface Suffix.

One thing people don't realise is that It's actually trivial to write your own internal eslint rules to enforce whatever conventions you would like.

For example, (I know it's going to be significantly faster for me to do because I have in-depth knowledge of eslint), but it took me about 5 minutes to write a rule with a fixer to enforce the suffix convention:
https://astexplorer.net/#/gist/61474b86c2de56ff3a808079e27f07ef/76054adb45accba8882af8a2b9269149f93a9dfc

[lukescott]

I use intellisense with code reviews as well. We use Bitbucket, so we use the Atlassian plugin to do code-reviews inside of vscode. If I cared whether a type was an interface or a class I would need to follow the definition anyway. In general, for our team, an I prefix provides no extra value. We also rarely have colliding interface and class names.

[vincentcr]

@bradzacher Obviously, disabling or working around the rule is always possible; the discussion should be whether it deserves to be a default. I still haven't heard a positive reason why this rule should be enabled, except to help C#/Java devs ease themselves into Typescript/Javascript. Outside of this historical context, the rule makes little sense.

[bradzacher]

This rule exists to help prevent people from introducing a typescript anti-pattern into their codebase.

I still haven't heard a positive reason why this rule should be enabled

In this thread and others linked, I have put forward the following reasons that you should not use this naming convention:

• IFoo is not clear to anyone that doesn't know the convention.
  • i.e. anyone who has not been a "C#/Java dev"
• IFoo is very hard to catch in a code review when comparing against a related class Foo.
  • One character is very, very, very easy to miss in a code review, esp if you're reviewing on GitHub which doesn't special colour them or provide types on hover.
• FooInterface, on the other hand, is very explicit, understandable for all developers, and very easy to distinguish from a related class Foo.
  • As shown before; with IDE tooling, there's no discernible speed difference between typing IFoo and FooInterface.
• interfaces are 99.99% functionally identical to types.
  • Unless you're using declaration merging, you could functionally switch out all your interface declarations for types and nothing would change. So why should they be specially prefixed with I?
• The TypeScript team explicitly recommends against this naming convention within their style docs.
  • Whilst they mention their docs are not a bible for writing TypeScript outside their repos, we take a lot of cues from their style guide because they use these conventions in their documentation, so it's how people learn TypeScript outside of an existing codebase.

The question I've been looking for an answer to is this: Why do you want to treat interfaces as a special naming case?
And these questions by extension:

• Why are you not naming types with T to differentiate them from non-types?
• Why don't you name classes with C to differentiate them from standard variables?
• Why don't you name functions with F to differentiate them from non-functions?
• Why don't you name let vars with an L to differentiate them from const vars?
• Why are you not using hungarian notation for your variables to name number variables with an N, and strings with an S (etc)?

Sure, I got a little silly toward the end, more or less leading into a slippery slope argument, but the questions are still valid.

If you boil it down, the response I keep getting is "I want to use I prefixed interface names in my codebase because I want to.". As mentioned earlier, this is not a reason that it should be removed from the recommended set.

Your IDE will provide you ample tooling to help you differentiate everything above. So again - why provide interfaces with that extra bit of recognisability and not anything else?

Sure, there are a few edge cases (such as falsely reporting IBAN when it's an acronym, and not shorthand for InterfaceBAN), however these can be worked around with a disable comment. Better still we could handle these edge cases by updating the rule's regex or, if it's too complex a name, by adding a rule option to allow specific names.

Similar to my example with the camelcase rule - IMO these edge cases are not reasons to entirely disable the rule.

---

Ultimately, we are discussing the recommended set. Discussing what the recommended way to program TypeScript is.

We are recommending that you don't follow this naming convention for the reasons I laid out above.

The reason that I've left this issue open is that I'm hoping someone will bring an argument that isn't "because I want to".

[lukescott]

@bradzacher I agree with you that an interface should not be prefixed with I. And I think the assumption is that recommended is always, but the default of typescript-eslint is actually error (meaning never). I think there is some confusion on this because the default of tslint is always-prefix. And a similar issue on the tslint side recommends coming here to further discuss it because tslint is being deprecated in favor of typescript-eslint.

The current default typescript-eslint is actually what most of us already do. So I don't think there is a problem there. If there was any change, it would be to simply not care either way and not have it exist in recommended at all (which the OP suggests), so people could name their interfaces however they want. However, the current default (which, again is the opposite of tslint) does prefer people not prefix with I.

Sorry for the confusion on my end as I did not realize this until now. We are still in a transition period, and I was simply continuing the conversation from tslint.

[nonameolsson]

So, is there any way to have the rule that an interface MUST start with I?

[bradzacher]

Please have a read of the rule docs for interface-name-prefix: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/interface-name-prefix.md

---

I'm going to close this. #651 outlines the recommeneded changes we're making for 2.0 release. We will not be removing interface-name-prefix from the recommended set.