eslint-plugin-nextfriday 1.15.2 → 1.16.0

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # eslint-plugin-nextfriday
 
+## 1.16.0
+
+### Minor Changes
+
+- [#75](https://github.com/next-friday/eslint-plugin-nextfriday/pull/75) [`f506561`](https://github.com/next-friday/eslint-plugin-nextfriday/commit/f506561c1587af4a129801dee87c7ed08154b090) Thanks [@joetakara](https://github.com/joetakara)! - feat(rules): add prefer-inline-literal-union, no-nested-interface-declaration, and enforce-type-declaration-order rules
+
 ## 1.15.2
 
 ### Patch Changes

package/README.md

@@ -113,7 +113,10 @@ export default [
       "nextfriday/sort-imports": "error",
 
       // Type Patterns
+      "nextfriday/enforce-type-declaration-order": "error",
+      "nextfriday/no-nested-interface-declaration": "error",
       "nextfriday/prefer-named-param-types": "error",
+      "nextfriday/prefer-inline-literal-union": "error",
       "nextfriday/prefer-interface-over-inline-types": "error",
       "nextfriday/sort-type-alphabetically": "error",
       "nextfriday/sort-type-required-first": "error",
@@ -225,7 +228,10 @@ module.exports = {
 
 | Rule                                                                                   | Description                                                      | Fixable |
 | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------- |
+| [enforce-type-declaration-order](docs/rules/ENFORCE_TYPE_DECLARATION_ORDER.md)         | Enforce referenced types are declared after their consumer       | ❌      |
+| [no-nested-interface-declaration](docs/rules/NO_NESTED_INTERFACE_DECLARATION.md)       | Disallow inline object types in interface/type properties        | ❌      |
 | [prefer-named-param-types](docs/rules/PREFER_NAMED_PARAM_TYPES.md)                     | Enforce named types for function parameters with object types    | ❌      |
+| [prefer-inline-literal-union](docs/rules/PREFER_INLINE_LITERAL_UNION.md)               | Enforce inlining literal union types for better IDE hover info   | ✅      |
 | [prefer-interface-over-inline-types](docs/rules/PREFER_INTERFACE_OVER_INLINE_TYPES.md) | Enforce interface declarations over inline types for React props | ❌      |
 | [sort-type-alphabetically](docs/rules/SORT_TYPE_ALPHABETICALLY.md)                     | Enforce A-Z sorting of properties within type groups             | ✅      |
 | [sort-type-required-first](docs/rules/SORT_TYPE_REQUIRED_FIRST.md)                     | Enforce required properties before optional in types/interfaces  | ✅      |
@@ -259,14 +265,14 @@ module.exports = {
 
 | Preset               | Severity | Base Rules | JSX Rules | Next.js Rules | Total Rules |
 | -------------------- | -------- | ---------- | --------- | ------------- | ----------- |
-| `base`               | warn     | 33         | 0         | 0             | 33          |
-| `base/recommended`   | error    | 33         | 0         | 0             | 33          |
-| `react`              | warn     | 33         | 14        | 0             | 47          |
-| `react/recommended`  | error    | 33         | 14        | 0             | 47          |
-| `nextjs`             | warn     | 33         | 14        | 1             | 48          |
-| `nextjs/recommended` | error    | 33         | 14        | 1             | 48          |
+| `base`               | warn     | 36         | 0         | 0             | 36          |
+| `base/recommended`   | error    | 36         | 0         | 0             | 36          |
+| `react`              | warn     | 36         | 14        | 0             | 50          |
+| `react/recommended`  | error    | 36         | 14        | 0             | 50          |
+| `nextjs`             | warn     | 36         | 14        | 1             | 51          |
+| `nextjs/recommended` | error    | 36         | 14        | 1             | 51          |
 
-### Base Configuration Rules (33 rules)
+### Base Configuration Rules (36 rules)
 
 Included in `base`, `base/recommended`, and all other presets:
 
@@ -276,6 +282,7 @@ Included in `base`, `base/recommended`, and all other presets:
 - `nextfriday/enforce-hook-naming`
 - `nextfriday/enforce-service-naming`
 - `nextfriday/enforce-sorted-destructuring`
+- `nextfriday/enforce-type-declaration-order`
 - `nextfriday/file-kebab-case`
 - `nextfriday/md-filename-case-restriction`
 - `nextfriday/newline-after-multiline-block`
@@ -288,6 +295,7 @@ Included in `base`, `base/recommended`, and all other presets:
 - `nextfriday/no-inline-nested-object`
 - `nextfriday/no-lazy-identifiers`
 - `nextfriday/no-logic-in-params`
+- `nextfriday/no-nested-interface-declaration`
 - `nextfriday/no-nested-ternary`
 - `nextfriday/no-relative-imports`
 - `nextfriday/no-single-char-variables`
@@ -296,6 +304,7 @@ Included in `base`, `base/recommended`, and all other presets:
 - `nextfriday/prefer-function-declaration`
 - `nextfriday/prefer-guard-clause`
 - `nextfriday/prefer-import-type`
+- `nextfriday/prefer-inline-literal-union`
 - `nextfriday/prefer-named-param-types`
 - `nextfriday/prefer-react-import-types`
 - `nextfriday/require-explicit-return-type`

package/docs/rules/ENFORCE_TYPE_DECLARATION_ORDER.md

@@ -0,0 +1,87 @@
+# enforce-type-declaration-order
+
+Enforce that referenced types and interfaces are declared after the type that uses them.
+
+## Rule Details
+
+This rule enforces a top-down reading order for type declarations. When an interface or type references another locally-declared type, the referenced (dependency) type must appear _after_ the consumer. This ensures the "main" type is read first, with its supporting types following below.
+
+### Why?
+
+1. **Top-down readability**: The primary type appears first, making it easy to understand the high-level structure before drilling into details
+2. **Consistency**: A uniform ordering convention eliminates debates about where to place types
+3. **Natural flow**: Mirrors how you'd explain a data structure - start with the big picture, then define the parts
+
+## Examples
+
+### Incorrect
+
+```ts
+// Dependency declared before consumer
+interface Baz {
+  baz: string;
+}
+
+interface Foo {
+  bar: Baz;
+}
+```
+
+```ts
+type Config = {
+  theme: string;
+};
+
+type Props = {
+  config: Config;
+};
+```
+
+### Correct
+
+```ts
+// Consumer first, dependency after
+interface Foo {
+  bar: Baz;
+}
+
+interface Baz {
+  baz: string;
+}
+```
+
+```ts
+type Props = {
+  config: Config;
+};
+
+type Config = {
+  theme: string;
+};
+```
+
+```ts
+// Chain of dependencies in top-down order
+interface Parent {
+  child: Child;
+}
+
+interface Child {
+  grandchild: Grandchild;
+}
+
+interface Grandchild {
+  value: string;
+}
+```
+
+```ts
+// External/imported types are ignored (not locally declared)
+interface Props {
+  items: ExternalType[];
+}
+```
+
+## When Not To Use It
+
+If you prefer declaring dependency types before the types that reference them (bottom-up order), or if you don't want to enforce any particular declaration order, you can disable this rule.

package/docs/rules/NO_NESTED_INTERFACE_DECLARATION.md

@@ -0,0 +1,102 @@
+# no-nested-interface-declaration
+
+Disallow inline object type literals in interface or type properties.
+
+## Rule Details
+
+This rule flags inline object type literals nested inside interface or type properties. Nested object types should be extracted into separate named interfaces or type declarations for clarity and reusability.
+
+### Why?
+
+1. **Readability**: Deeply nested inline types make interfaces harder to scan
+2. **Reusability**: Extracted types can be imported and reused across files
+3. **Maintainability**: Flat, named types are easier to modify and extend
+4. **IDE experience**: Named types provide better hover information and navigation
+
+## Examples
+
+### Incorrect
+
+```ts
+interface Foo {
+  bar: {
+    baz: string;
+  };
+}
+```
+
+```ts
+interface Props {
+  user: {
+    name: string;
+    age: number;
+  };
+}
+```
+
+```ts
+interface Props {
+  items: {
+    id: number;
+    label: string;
+  }[];
+}
+```
+
+```ts
+interface Props {
+  data: Readonly<{
+    id: number;
+    name: string;
+  }>;
+}
+```
+
+### Correct
+
+```ts
+interface Bar {
+  baz: string;
+}
+
+interface Foo {
+  bar: Bar;
+}
+```
+
+```ts
+interface User {
+  name: string;
+  age: number;
+}
+
+interface Props {
+  user: User;
+}
+```
+
+```ts
+interface Item {
+  id: number;
+  label: string;
+}
+
+interface Props {
+  items: Item[];
+}
+```
+
+```ts
+// Primitive and simple types are fine inline
+interface Props {
+  name: string;
+  age: number;
+  isActive: boolean;
+  ids: string[];
+  callback: () => void;
+}
+```
+
+## When Not To Use It
+
+If you prefer keeping small object types inline within interfaces for co-location, you can disable this rule.

package/docs/rules/PREFER_INLINE_LITERAL_UNION.md

@@ -0,0 +1,87 @@
+# prefer-inline-literal-union
+
+Enforce inlining literal union types in interface properties instead of using type aliases for better IDE hover information.
+
+This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
+
+## Rule Details
+
+This rule detects type aliases that are unions of only literal values (strings, numbers, booleans, null, undefined) and flags their usage in interface or type properties. The fix inlines the union directly into the property type annotation.
+
+### Why?
+
+When you hover over a prop in your IDE, a type alias shows the alias name (e.g., `ArticleFaqCategoryId`) instead of the actual values (`"articles" | "dharma" | "faq"`). Inlining literal unions gives immediate visibility into the allowed values without needing to jump to the type definition.
+
+## Examples
+
+### Incorrect
+
+```ts
+type ArticleFaqCategoryId = "articles" | "dharma" | "faq";
+
+interface ArticleFaqCategoryFilterProps {
+  activeCategoryId?: ArticleFaqCategoryId;
+}
+```
+
+```ts
+type Status = "loading" | "success" | "error";
+
+interface Props {
+  status: Status;
+}
+```
+
+```ts
+type Size = 1 | 2 | 3 | 4;
+
+interface Props {
+  size: Size;
+}
+```
+
+### Correct
+
+```ts
+interface ArticleFaqCategoryFilterProps {
+  activeCategoryId?: "articles" | "dharma" | "faq";
+}
+```
+
+```ts
+interface Props {
+  status: "loading" | "success" | "error";
+}
+```
+
+```ts
+interface Props {
+  size: 1 | 2 | 3 | 4;
+}
+```
+
+```ts
+// Non-literal unions are allowed as type aliases
+type User = { name: string; age: number };
+
+interface Props {
+  user: User;
+}
+```
+
+```ts
+// Using the alias outside of interface properties is fine
+type Status = "loading" | "success" | "error";
+function getStatus(s: Status): string {
+  return s;
+}
+```
+
+## When Not To Use It
+
+If you prefer using type aliases for literal unions (e.g., for reuse across multiple interfaces or for self-documenting code), you can disable this rule.
+
+## Further Reading
+
+- [TypeScript Union Types](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#union-types)
+- [TypeScript Literal Types](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types)