Forbid TypeScript interfaces #216
Merged
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
rekmarks
force-pushed
the
forbid-typescript-interfaces
branch
from
f85d1a3 to
0030943
Compare
mcmire
approved these changes
Nov 29, 2021
|
@mcmire updated description for clarity! |
rekmarks
added a commit
to MetaMask/key-tree
that referenced
this pull request
Dec 15, 2021
We hate interfaces, and they must be driven from this Earth in favor of object types. Ref: MetaMask/eslint-config#216
3 tasks
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.
TypeScript interfaces suck, they don't work with our
Jsontype, and it's high time that we abolish them from every part of our codebase.To wit, the only thing that can be done with an interface that cannot be done with a type is declaration merging, which is a "good language feature" in much the same way that a knife without a handle is a "good cooking instrument". All of the actually good stuff – IMO first and foremost
extendsandimplements– is also supported by object types (in this case, via&andimplements).So, if we have two language features A and B, where the capabilities of A are a strict superset of those of B, and using B at all will sometimes cause uses supported by A to fail, the only sane thing to do is get rid of B. "B" is interfaces. Long live interfaces!