feat(eslint-plugin): add consistent-type-definitions rule

[otofu-square]

ref #142

Adds prefer-type-alias rule which is the inverse of prefer-interface

Adds consistent-type-definitions rule to consist type definitions interface or type.

[codecov]

Codecov Report

Merging #463 into master will decrease coverage by 0.02%.
The diff coverage is 90.32%.

@@            Coverage Diff             @@
##           master     #463      +/-   ##
==========================================
- Coverage   94.25%   94.22%   -0.03%     
==========================================
  Files         107      108       +1     
  Lines        4388     4419      +31     
  Branches     1208     1217       +9     
==========================================
+ Hits         4136     4164      +28     
  Misses        147      147              
- Partials      105      108       +3

Impacted Files	Coverage Δ
...ckages/eslint-plugin/src/rules/prefer-interface.ts	93.75% <ø> (ø)	⬆️
packages/eslint-plugin/src/rules/index.ts	100% <100%> (ø)	⬆️
...nt-plugin/src/rules/consistent-type-definitions.ts	90% <90%> (ø)

[bradzacher]

Hey @otofu-square - thanks for doing this!

Could you please "merge" the two rules (your new prefer-type-alias, and prefer-interface) together?
I suggest the new rule be named: consistent-type-definitions.

---

One goal of eslint is to prevent the ability to get yourself into inconsistent states via config.
If we create this as a separate rule, then a user could turn on both rules, and have one rule telling them to use types instead of interfaces, and the other telling them to use interfaces instead of types.
(as an aside - down the line we'll have to look at merging in no-type-alias as well, but don't worry about that for now!)

---

You won't be able to delete prefer-interface (as that would be a breaking change), but you can remove its row from the root README.md, and mark it as deprecated by adding the following properties to its meta:

{
    "deprecated": true,
    "replacedBy": "consistent-type-definitions"
}

[otofu-square]

@bradzacher
Thanks for the suggestion!
The naming consistent-type-definitions looks great.
I'll give it a try to merge two rules.

If we create this as a separate rule, then a user could turn on both rules, and have one rule telling them to use types instead of interfaces, and the other telling them to use interfaces instead of types.

I see.
That’s very helpful for me, I learn something important about creating the eslint rules.

[otofu-square]

@bradzacher
Do you think what would be a good option schema for consistent-type-definitions rule to switch the setting between prefer-interface and prefer-type-alias?
I came up with the schema like below, but I don't know if it is the best.

...
schema: [
  {
    type: 'object',
    properties: {
      preferDeclaration: {
        enum: [
          'type',
          'interface',
        ],
      },
    }
  }
]

[bradzacher]

In this case, I would say that generally the preference for rule config is to have the first argument be a string, followed by an object for additional config items.

I.e. As a tuple type it'd be

type Options = [
  ('type' | 'interface')?,
  {
    opt1 ?: value,
  }?,
];

[otofu-square]

@bradzacher
Please review my implementation once.
I'll give it a try to write docs if that is ok.

[bradzacher]

you should avoid force pushing when possible.
if you force push, then github cannot track your history, as your force push obliterates it!

---

don't forget to import your rule into index.ts in the root of the plugin.

---

the rule code looks good to me!
Just need to create a readme for the rule

[otofu-square]

Thanks for your review.

you should avoid force pushing when possible.
if you force push, then github cannot track your history, as your force push obliterates it!

It makes sense to me!

don't forget to import your rule into index.ts in the root of the plugin.

Oops, got it.

[bradzacher]

it all LGTM

[otofu-square]

@bradzacher
Have done writing the doc for this rule 👍

[bradzacher]

Docs mostly look good.

Would suggest two things:

1. move your "Options" section so that it is before "Rule Details"
2. You could shorten the section so it's a bit clearer:

    ### Options

    This rule accepts one string option:
    - `"interface"`: enforce using `interface`s for object type definitions.
    - `"type"`: enforce using `type`s for object type definitions.

    For example:
    ```CJSON
    {
        // Use type for object definitions
        "@typescript-eslint/consistent-type-definitions": ["error", "type"]
    }
    ```

[leoyli]

Oh, I really love to have this rule come alive!!! 👍 Thank you for this great work!!!

[bradzacher]

@otofu-square - there are two merge conflicts which need resolving (github thinks they're too "complex", so I can't do them for you via the github web UI).

Once they're resolved I will merge to master.

[otofu-square]

@bradzacher
Should I leave the prefer-interface docs?
CI checks have failed because of that docs does not exist.

[bradzacher]

@otofu-square - that looks like a bug in the documentation checker! I'll look into it tomorrow morning.