Repository navigation
feat: prefer type definitions - #22
jobveldhuis wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 8e9ecf0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
🟡 Changes recommended
The new rule conflicts with the existing TypeDoc interface policy and documentation.
2 open findings
What changed in this PR
Enforces type aliases over interfaces across the shared ESLint configuration and documents limited exceptions.
Changes:
- Enables
consistent-type-definitions. - Expands type-definition guidance and exceptions.
- Adds a major-version changeset.
| File | Description |
|---|---|
STYLE-GUIDE.md |
Documents preferred type definitions. |
packages/eslint/src/partials/typescript.ts |
Enforces type aliases. |
.changeset/prefer-type-definitions.md |
Records the breaking change. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| // `Record<string, unknown>`. Module augmentation and large `extends` | ||
| // hierarchies are valid reasons to disable this rule for one line. | ||
| "@typescript-eslint/consistent-type-definitions": ["error", "type"], |
| There are two exceptions where an interface is the better choice: | ||
|
|
||
| - **Module augmentation.** Extending a type declared by a library (like `Window`, or React Router's `Register`) relies on declaration merging, which only interfaces support. | ||
| - **Large hierarchies of object types.** When an object type is built by extending several others, prefer `interface … extends` over intersections (`&`). `extends` reports conflicting properties as an error, while an intersection silently turns them into `never`. Typescript also caches `extends` relationships, which keeps type checking fast in large codebases. |
|
This comment from Copilot is very valid. I chose not to add this rule earlier because there's valid exceptions for this rule, and adding an exception to every public interface because you use Typedoc to generate documentation is also not the solution IMO. I think this warrants a discussion; do we need to update / change the rule? The arguments mentioned are valid, but do they warrant the downsides? We could probably also prevent automatic merging of interfaces using a different ESLint rule, and the "Large hierarchies of object types." exception happens in enough code bases that requiring exceptions becomes awkward IMO. We should either:
|
I'm fine not adding the rule and leaving it to reviews. |
Ensures that our linting config is actually up-to-date with the idea of types instead of interfaces.