Drop @typescript-eslint/consistent-type-definitions rule

[fregante]

Related:

• Enable @typescript-eslint/consistent-type-definitions rule #57

This rule’s autofix breaks code like declaration merging, it's not safe nor it is particularly useful other than enforcing a specific style.

Also:

• https://twitter.com/drosenwasser/status/1319205169918144513

[EdJoPaTo]

Just to bring it up… how about using '@typescript-eslint/consistent-type-definitions': ['error', 'interface'] instead?

As far as I understand it should migrate interfaces written as types to interfaces? I have not tested it nor have I checked what breakage might be resulted from that.

I am quite sure writing all the interfaces as types can break a lot but most projects I know of dont use types of interface style declarations anyway.

(I am in support of dropping this rule with 'type', but I would consider thinking about 'interface' before dropping it completely)

[sindresorhus]

This rule’s autofix breaks code like declaration merging, it's not safe nor it is particularly useful other than enforcing a specific style.

This is a problem with the rule itself and should be opened on https://github.com/typescript-eslint/typescript-eslint

[sindresorhus]

Enforcing a specific style is literally one of the reasons this repo exists. Declaration merging is IMHO an anti-pattern that should be used sparingly (the best analogy for it is modifying String.prototype). Yes, it makes sense to use sometimes to fix bad types, but in general, I think type is better.

[fregante]

I'm literally this close to publishing eslint-config-like-xo-but-less-idealistic