Re-enable @typescript-eslint/consistent-type-definitions #1933
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Ah, you are right. Hmm. This makes me wonder why we chose to enforce type aliases instead of interfaces again. I will think about this. |
|
This is the commit in |
This comment was marked as outdated.
This comment was marked as outdated.
MajorLift
previously approved these changes
Oct 27, 2023
Convert all uses of `interface` to `type`, taking care to reverse cases in which interfaces are extending other interfaces (`A extends B` should come out to `B & A`).
mcmire
force-pushed
the
reenable-consistent-type-definitions
branch
from
b344fc6 to
06db854
Compare
|
I rebased this branch, as the history somehow got corrupted after merging I've addressed the existing violations by adding inline overrides instead of converting them to Ready for another review. |
|
Fixed merge conflicts. |
This was referenced Feb 27, 2024
This was referenced Mar 11, 2024
MajorLift
added a commit
to MetaMask/metamask-extension
that referenced
this pull request
Mar 14, 2024
…eslint/consistent-type-definitions` rule (#23439) ## **Description** ### Motivation `interface` usage is banned in MetaMask codebases. With TypeScript conversion efforts in progress, it's time to enforce `type` usage over `interface` in the extension codebase as well, especially for new contributions in TypeScript. There are a few reasons for banning `interface`: - Interfaces do not extend `Record` or have a `string` index signature by default, making them incompatible with the data/state objects we use. - The feature set of type aliases is a strict superset of that of interfaces (including `extends`, `implements`). - Declaration merging is an exception, but this is not a practice we want to encourage. For more context, see these links for previous discussions on this topic: - MetaMask/eslint-config#216 - MetaMask/core#1933 ### Explanation The `@typescript-eslint/consistent-type-definitions` has been configured with the `["error", "type"]` options, which will prevent the `interface` keyword from being introduced into the codebase in the future. Existing instances of `interface` usage in the codebase were converted to type alias definitions. For the following exceptions, the `interface` keyword was preserved with a `eslint-disable` directive, and a TODO comment was added for future conversion. 1. If the `interface` is declared with an `extends` keyword. - This is because of possible type accuracy issues with the eslint autofix appending the extending interface as an intersection (`&`). 2. If the `interface` is used for declaration merging. - This is the only use case for interfaces that is not supported by type aliases, and is therefore a valid exception to the ESLint rule. [](https://codespaces.new/MetaMask/metamask-extension/pull/23439?quickstart=1) ## **Related issues** - Closes #23442 ## **Manual testing steps** ## **Screenshots/Recordings** ## **Pre-merge author checklist** - [x] I’ve followed [MetaMask Coding Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md). - [x] I've clearly explained what problem this PR is solving and how it is solved. - [x] I've linked related issues - [ ] I've included manual testing steps - [ ] I've included screenshots/recordings if applicable - [ ] I’ve included tests if applicable - [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. - [x] I’ve properly set the pull request status: - [x] In case it's not yet "ready for review", I've set it to "draft". - [x] In case it's "ready for review", I've changed it from "draft" to "non-draft". ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.
](https://codespaces.new/MetaMask/metamask-extension/pull/23439?quickstart=1){kind=link}
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
This ESLint rule was disabled in a previous commit when our ESLint config packages were bumped, because it caused lint violations.
This commit re-enables this rule going forward. However, since fixing the lint violations by converting
interfaces totypes would cause breaking changes, this commit adds inline overrides to allow existinginterfaces to exist.References
Fixes #1932.
Changelog
(No consumer-facing changes.
Checklist