eslint-plugin-code-style 1.1.10 → 1.2.6

package/README.md

@@ -7,9 +7,10 @@
 [![License](https://img.shields.io/npm/l/eslint-plugin-code-style?style=for-the-badge&color=blue)](https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/blob/main/LICENSE)
 
 [![ESLint](https://img.shields.io/badge/ESLint-%3E%3D9.0.0-4B32C3?style=for-the-badge&logo=eslint&logoColor=white)](https://eslint.org/)
-[![Node.js](https://img.shields.io/badge/Node.js-%3E%3D18.0.0-339933?style=for-the-badge&logo=node.js&logoColor=white)](https://nodejs.org/)
+[![Node.js](https://img.shields.io/badge/Node.js-%3E%3D20.0.0-339933?style=for-the-badge&logo=node.js&logoColor=white)](https://nodejs.org/)
 [![React](https://img.shields.io/badge/React-JSX%20Support-61DAFB?style=for-the-badge&logo=react&logoColor=black)](https://react.dev/)
-[![TypeScript](https://img.shields.io/badge/TypeScript-Supported-3178C6?style=for-the-badge&logo=typescript&logoColor=white)](https://www.typescriptlang.org/)
+[![TypeScript](https://img.shields.io/badge/TypeScript-%3E%3D5.0.0-3178C6?style=for-the-badge&logo=typescript&logoColor=white)](https://www.typescriptlang.org/)
+[![Tailwind CSS](https://img.shields.io/badge/Tailwind%20CSS-%3E%3D4.0.0-06B6D4?style=for-the-badge&logo=tailwindcss&logoColor=white)](https://tailwindcss.com/)
 
 [![GitHub stars](https://img.shields.io/github/stars/Mohamed-Elhawary/eslint-plugin-code-style?style=for-the-badge&logo=github&color=yellow)](https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/stargazers)
 [![GitHub issues](https://img.shields.io/github/issues/Mohamed-Elhawary/eslint-plugin-code-style?style=for-the-badge&logo=github)](https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/issues)
@@ -18,7 +19,7 @@
 
 **A powerful ESLint plugin for enforcing consistent code formatting and style rules in React/JSX projects.**
 
-*51 auto-fixable rules to keep your codebase clean and consistent*
+*60 auto-fixable rules to keep your codebase clean and consistent*
 
 </div>
 
@@ -26,7 +27,7 @@
 
 ## 🎯 Why This Plugin?
 
-This plugin provides **51 custom auto-fixable rules** for code formatting. Built for **ESLint v9 flat configs**.
+This plugin provides **60 custom auto-fixable rules** for code formatting. Built for **ESLint v9 flat configs**.
 
 > **Note:** ESLint [deprecated 79 formatting rules](https://eslint.org/blog/2023/10/deprecating-formatting-rules/) in v8.53.0. Our recommended configs use `@stylistic/eslint-plugin` as the replacement for these deprecated rules.
 
@@ -35,7 +36,7 @@ This plugin provides **51 custom auto-fixable rules** for code formatting. Built
 - **Works alongside existing tools** — Complements ESLint's built-in rules and packages like eslint-plugin-react, eslint-plugin-import, etc
 - **Self-sufficient rules** — Each rule handles complete formatting independently
 - **Consistency at scale** — Reduces code-style differences between team members by enforcing uniform formatting across your projects
-- **Fully automated** — All 47 rules support auto-fix, eliminating manual style reviews
+- **Fully automated** — All 60 rules support auto-fix, eliminating manual style reviews
 
 When combined with ESLint's native rules and other popular plugins, this package helps create a complete code style solution that keeps your codebase clean and consistent.
 
@@ -59,17 +60,19 @@ We provide **ready-to-use ESLint flat configuration files** that combine `eslint
 
 ### 💡 Why Use These Configs?
 
-- **Complete Coverage** — Combines ESLint built-in rules, third-party plugins, and all 51 code-style rules
+- **Complete Coverage** — Combines ESLint built-in rules, third-party plugins, and all 60 code-style rules
 - **Ready-to-Use** — Copy the config file and start linting immediately
 - **Battle-Tested** — These configurations have been refined through real-world usage
 - **Fully Documented** — Each config includes detailed instructions and explanations
 
 ### 📋 Available Configurations
 
-| Configuration | Description | Link |
-|---------------|-------------|------|
+| Configuration | Description | Status |
+|---------------|-------------|--------|
 | **React** | React.js projects (JavaScript, JSX) | [View Config](./recommended-configs/react/) |
 | **React + TS + Tailwind** | React + TypeScript + Tailwind CSS | [View Config](./recommended-configs/react-ts-tw/) |
+| **React + TypeScript** | React + TypeScript projects | Coming Soon |
+| **React + Tailwind** | React + Tailwind CSS projects | Coming Soon |
 
 ### ⚡ Quick Start with Recommended Config
 
@@ -94,7 +97,7 @@ We provide **ready-to-use ESLint flat configuration files** that combine `eslint
 <td width="50%">
 
 ### 🔧 Auto-Fixable Rules
-All **51 rules** support automatic fixing with `eslint --fix`. No manual code changes needed.
+All **60 rules** support automatic fixing with `eslint --fix`. No manual code changes needed.
 
 </td>
 <td width="50%">
@@ -140,7 +143,7 @@ yarn add eslint-plugin-code-style -D
 | Dependency | Version |
 |------------|---------|
 | **ESLint** | `>= 9.0.0` |
-| **Node.js** | `>= 18.0.0` |
+| **Node.js** | `>= 20.0.0` |
 
 <br />
 
@@ -178,28 +181,35 @@ eslint src/ --fix
 
 ```javascript
 rules: {
+    "code-style/absolute-imports-only": "error",
     "code-style/array-items-per-line": "error",
     "code-style/array-objects-on-new-lines": "error",
     "code-style/arrow-function-block-body": "error",
     "code-style/arrow-function-simple-jsx": "error",
     "code-style/arrow-function-simplify": "error",
-    "code-style/curried-arrow-same-line": "error",
     "code-style/assignment-value-same-line": "error",
     "code-style/block-statement-newlines": "error",
+    "code-style/classname-dynamic-at-end": "error",
+    "code-style/classname-multiline": "error",
+    "code-style/classname-no-extra-spaces": "error",
     "code-style/comment-format": "error",
+    "code-style/component-props-destructure": "error",
+    "code-style/component-props-inline-type": "error",
+    "code-style/curried-arrow-same-line": "error",
+    "code-style/enum-format": "error",
+    "code-style/export-format": "error",
+    "code-style/function-arguments-format": "error",
     "code-style/function-call-spacing": "error",
     "code-style/function-naming-convention": "error",
+    "code-style/function-object-destructure": "error",
     "code-style/function-params-per-line": "error",
     "code-style/hook-callback-format": "error",
     "code-style/hook-deps-per-line": "error",
     "code-style/if-statement-format": "error",
-    "code-style/multiline-if-conditions": "error",
-    "code-style/absolute-imports-only": "error",
-    "code-style/export-format": "error",
     "code-style/import-format": "error",
     "code-style/import-source-spacing": "error",
     "code-style/index-export-style": "error",
-    "code-style/module-index-exports": "error",
+    "code-style/interface-format": "error",
     "code-style/jsx-children-on-new-line": "error",
     "code-style/jsx-closing-bracket-spacing": "error",
     "code-style/jsx-element-child-new-line": "error",
@@ -210,7 +220,8 @@ rules: {
     "code-style/jsx-string-value-trim": "error",
     "code-style/jsx-ternary-format": "error",
     "code-style/member-expression-bracket-spacing": "error",
-    "code-style/function-arguments-format": "error",
+    "code-style/module-index-exports": "error",
+    "code-style/multiline-if-conditions": "error",
     "code-style/nested-call-closing-brackets": "error",
     "code-style/no-empty-lines-in-function-calls": "error",
     "code-style/no-empty-lines-in-function-params": "error",
@@ -221,14 +232,14 @@ rules: {
     "code-style/object-property-value-brace": "error",
     "code-style/object-property-value-format": "error",
     "code-style/opening-brackets-same-line": "error",
+    "code-style/react-code-order": "error",
     "code-style/simple-call-single-line": "error",
     "code-style/single-argument-on-one-line": "error",
     "code-style/string-property-spacing": "error",
-    "code-style/variable-naming-convention": "error",
-    "code-style/enum-format": "error",
-    "code-style/interface-format": "error",
+    "code-style/type-annotation-spacing": "error",
     "code-style/type-format": "error",
     "code-style/typescript-definition-location": "error",
+    "code-style/variable-naming-convention": "error",
 }
 ```
 
@@ -238,7 +249,7 @@ rules: {
 
 ## 📖 Rules Summary
 
-> All **51 rules** are auto-fixable. See detailed examples for each rule in the [Rules Reference](#-rules-reference) section below.
+> All **60 rules** are auto-fixable. See detailed examples for each rule in the [Rules Reference](#-rules-reference) section below.
 >
 > Rules marked with ⚙️ support customization options (e.g., extending default folder lists).
 
@@ -257,10 +268,13 @@ rules: {
 | `nested-call-closing-brackets` | Chain closing brackets on same line: `}));` not scattered across lines |
 | `no-empty-lines-in-function-calls` | No empty lines between arguments or after `(`/before `)` |
 | `opening-brackets-same-line` | Opening `{`, `[`, or `(` on same line as function call, not on new line |
-| `simple-call-single-line` | Collapse simple `fn(() => call())` patterns to single line |
+| `simple-call-single-line` | Collapse simple arrow function calls to single line (including callbacks with params and optional chaining) |
 | `single-argument-on-one-line` | Single simple argument stays on one line: `fn(x)` not expanded |
 | **Comment Rules** | |
 | `comment-format` | Space after `//`, space inside `/* */`, convert single-line blocks to `//`, no blank lines between file-top comments |
+| **Component Rules** | |
+| `component-props-destructure` | Component props must be destructured `({ prop })` not received as `(props)` |
+| `component-props-inline-type` | Inline type annotation `} : {` with matching props, proper spacing, commas, no interface reference |
 | **Control Flow Rules** | |
 | `block-statement-newlines` | Newline after `{` and before `}` in if/for/while/function blocks |
 | `if-statement-format` | `{` on same line as `if`/`else if`, `else` on same line as `}`, proper spacing |
@@ -269,6 +283,7 @@ rules: {
 | **Function Rules** | |
 | `function-call-spacing` | No space between function name and `(`: `fn()` not `fn ()` |
 | `function-naming-convention` | Functions use camelCase, start with verb (get/set/handle/is/has), handlers end with Handler |
+| `function-object-destructure` | Non-component functions: use typed params (not destructured), destructure in body; report dot notation access |
 | `function-params-per-line` | When multiline, each param on own line with consistent indentation |
 | `no-empty-lines-in-function-params` | No empty lines between parameters or after `(`/before `)` |
 | **Hook Rules** | |
@@ -282,6 +297,9 @@ rules: {
 | `index-export-style` | Index files: no blank lines, enforce shorthand or import-export style; Regular files: require blank lines between exports (default: shorthand) ⚙️ |
 | `module-index-exports` | Index files must export all folder contents (files and subfolders) ⚙️ |
 | **JSX Rules** | |
+| `classname-dynamic-at-end` | Dynamic expressions (`${className}`) must be at the end of class strings (JSX and variables) |
+| `classname-multiline` | Long className strings broken into multiple lines, one class per line; uses `"..."` in JSX (no expressions) or `` `...` `` (with expressions/variables) ⚙️ |
+| `classname-no-extra-spaces` | No extra/leading/trailing spaces in class strings (JSX, variables, and objects) |
 | `jsx-children-on-new-line` | Multiple JSX children: each on own line with proper indentation |
 | `jsx-closing-bracket-spacing` | No space before `>` or `/>` in JSX tags |
 | `jsx-element-child-new-line` | Nested JSX elements on new lines; text/expression children can stay inline |
@@ -304,10 +322,13 @@ rules: {
 | **TypeScript Rules** | |
 | `enum-format` | Enforce enum naming (PascalCase + Enum suffix), UPPER_CASE members, no empty lines, and trailing commas |
 | `interface-format` | Enforce interface naming (PascalCase + Interface suffix), camelCase properties, no empty lines, and trailing commas |
+| `type-annotation-spacing` | Enforce consistent spacing in type annotations: no space before colon/generic/array brackets, one space after colon |
 | `type-format` | Enforce type naming (PascalCase + Type suffix), camelCase properties, no empty lines, and trailing commas |
 | `typescript-definition-location` | Enforce TypeScript definitions (interfaces, types, enums) to be in designated folders ⚙️ |
+| **React Rules** | |
+| `react-code-order` | Enforce consistent ordering in components and hooks: props destructure → refs → state → redux → router → context → custom hooks → derived → memo → callback → handlers → effects → return |
 | **Variable Rules** | |
-| `variable-naming-convention` | camelCase for variables, UPPER_CASE for constants, PascalCase for components, `use` prefix for hooks |
+| `variable-naming-convention` | camelCase for all variables and constants, PascalCase for components, `use` prefix for hooks |
 
 <br />
 
@@ -707,17 +728,18 @@ items.map(
 
 ### `simple-call-single-line`
 
-**What it does:** Collapses simple function calls with an arrow function containing a single call expression onto one line.
+**What it does:** Collapses simple function calls with an arrow function onto one line when the result fits within 120 characters. Handles:
+- Zero-param callbacks: `lazy(() => import("./Page"))`
+- Callbacks with params and simple expression bodies: `.find((f) => f.code === x)`
+- Optional chaining: `.find(...)?.symbol`
 
-**Why use it:** Common patterns like `lazy(() => import(...))` don't need multiline formatting. Single line is cleaner.
+**Why use it:** Common patterns like `lazy(() => import(...))` and `.find((item) => item.id === id)` don't need multiline formatting. Single line is cleaner.
 
 ```javascript
 // ✅ Good — simple patterns on one line
 const Page = lazy(() => import("./Page"));
-const Modal = lazy(() => import("./Modal"));
 setTimeout(() => callback(), 100);
-requestAnimationFrame(() => render());
-items.filter(() => isValid(item));
+const symbol = items.find(({ code }) => code === currency)?.symbol;
 
 // ✅ Good — complex callbacks stay multiline
 const Page = lazy(() => {
@@ -730,10 +752,11 @@ const Page = lazy(
     () => import("./Page"),
 );
 
-setTimeout(
-    () => callback(),
-    100,
-);
+const symbol = items.find(({ code }) =>
+    code === currency)?.symbol;
+
+const symbol = items.find(({ code }) => code === currency)?.
+    symbol;
 ```
 
 ---
@@ -1091,6 +1114,57 @@ function get_user_data() {}
 
 ---
 
+### `function-object-destructure`
+
+**What it does:** Enforces that non-component functions should not destructure parameters in the function signature. Instead, use a typed parameter and destructure at the top of the function body. Also reports when parameters are accessed via dot notation (suggesting destructuring).
+
+**Why use it:** Keeping function signatures clean and short improves readability. Destructuring in the body makes it clear what properties are being used. For React components, this rule does NOT apply — components should destructure props in the signature.
+
+```typescript
+// ✅ Good — typed param with destructuring in body
+const createUserHandler = async (data: CreateUserParamsInterface) => {
+    const { age, email, isActive, name } = data;
+
+    // Use age, email, isActive, name...
+};
+
+const updateUserHandler = (params: UpdateParamsInterface) => {
+    const { id, updates } = params;
+
+    // Use id, updates...
+};
+
+// ✅ Good — React components CAN destructure in signature
+const UserCard = ({
+    name,
+    email,
+} : {
+    name: string,
+    email: string,
+}) => (
+    <div>{name} - {email}</div>
+);
+
+// ❌ Bad — non-component function destructures in signature
+const createUserHandler = async ({
+    age,
+    email,
+    isActive,
+    name,
+}: CreateUserParamsInterface) => {
+    // ...
+};
+
+// ❌ Bad — accessing param via dot notation (should destructure)
+const processDataHandler = (data: DataInterface) => {
+    console.log(data.id);      // Bad: use destructuring
+    console.log(data.name);    // Bad: use destructuring
+    return data.value * 2;     // Bad: use destructuring
+};
+```
+
+---
+
 ### `function-params-per-line`
 
 **What it does:** When function parameters span multiple lines, ensures each parameter is on its own line with consistent indentation.
@@ -1299,7 +1373,7 @@ import { fetchUsers } from "@/apis/users/fetchUsers";
 ```
 
 **Default Allowed Folders:**
-`actions`, `apis`, `assets`, `atoms`, `components`, `constants`, `contexts`, `data`, `enums`, `hooks`, `interfaces`, `layouts`, `middlewares`, `providers`, `reducers`, `redux`, `requests`, `routes`, `schemas`, `services`, `store`, `styles`, `theme`, `thunks`, `types`, `utils`, `views`
+`actions`, `apis`, `assets`, `atoms`, `components`, `config`, `configs`, `constants`, `contexts`, `data`, `enums`, `helpers`, `hooks`, `interfaces`, `layouts`, `lib`, `middlewares`, `providers`, `reducers`, `redux`, `requests`, `routes`, `schemas`, `services`, `store`, `styles`, `theme`, `thunks`, `types`, `ui`, `utils`, `utilities`, `views`
 
 **Customization Options:**
 
@@ -1543,7 +1617,7 @@ import { Button } from "@/components/Button/Button"; // Avoid this!
 ```
 
 **Default Module Folders:**
-`actions`, `apis`, `assets`, `atoms`, `components`, `constants`, `contexts`, `data`, `enums`, `hooks`, `interfaces`, `layouts`, `middlewares`, `providers`, `reducers`, `redux`, `requests`, `routes`, `schemas`, `services`, `store`, `styles`, `theme`, `thunks`, `types`, `utils`, `views`
+`actions`, `apis`, `assets`, `atoms`, `components`, `config`, `configs`, `constants`, `contexts`, `data`, `enums`, `helpers`, `hooks`, `interfaces`, `layouts`, `lib`, `middlewares`, `providers`, `reducers`, `redux`, `requests`, `routes`, `schemas`, `services`, `store`, `styles`, `theme`, `thunks`, `types`, `ui`, `utils`, `utilities`, `views`
 
 **Default Ignore Patterns:**
 `index.js`, `index.jsx`, `index.ts`, `index.tsx`, `.DS_Store`, `__tests__`, `__mocks__`, `*.test.js`, `*.test.jsx`, `*.test.ts`, `*.test.tsx`, `*.spec.js`, `*.spec.jsx`, `*.spec.ts`, `*.spec.tsx`
@@ -1572,6 +1646,132 @@ import { Button } from "@/components/Button/Button"; // Avoid this!
 
 ## ⚛️ JSX Rules
 
+### `classname-dynamic-at-end`
+
+**What it does:** Enforces that dynamic expressions in className template literals are placed at the end, after all static class names. Also applies to variables with names containing "class" or "Class".
+
+**Why use it:** When using Tailwind CSS with `tailwindcss/classnames-order`, static classes are automatically sorted. However, dynamic expressions like `${className}` or `${styles.button}` can break the visual order if placed in the middle. This rule ensures dynamic parts come last for consistent, readable class strings.
+
+```javascript
+// ✅ Good — dynamic expressions at the end (JSX)
+<div className={`flex items-center gap-4 ${className}`} />
+
+// ✅ Good — dynamic expressions at the end (variable)
+const buttonClasses = `flex items-center ${className} ${styles.button}`;
+
+// ❌ Bad — dynamic expression at the beginning
+<div className={`${className} flex items-center gap-4`} />
+
+// ❌ Bad — dynamic expression in the middle (variable)
+const buttonClasses = `flex ${className} items-center gap-4`;
+```
+
+---
+
+### `classname-multiline`
+
+**What it does:** Enforces that long className strings are broken into multiple lines, with each class on its own line. Triggers when either the class count exceeds `maxClassCount` (default: 3) or the string length exceeds `maxLength` (default: 80). Also enforces:
+- JSX `className` with no dynamic expressions uses `"..."` string literal format
+- JSX `className` with dynamic expressions uses `` {`...`} `` template literal format
+- Variables/object properties use `` `...` `` template literal for multiline (JS requires it)
+- No empty lines between classes or before/after the quotes
+- Under-threshold multiline classes are collapsed back to a single line
+
+Applies to JSX `className` attributes, variables with class-related names, and object properties within class-related objects.
+
+**Why use it:** Long single-line class strings are hard to read and review. Breaking them into one class per line makes diffs cleaner and classes easier to scan. Using string literals when no expressions are needed keeps the code simpler.
+
+```javascript
+// ✅ Good — JSX with no expressions uses "..." format
+<div
+    className="
+        flex
+        items-center
+        justify-center
+        rounded-lg
+        p-4
+    "
+/>
+
+// ✅ Good — JSX with expressions uses {`...`} format
+<div
+    className={`
+        flex
+        items-center
+        justify-center
+        ${className}
+    `}
+/>
+
+// ✅ Good — variable multiline uses template literal
+const buttonClasses = `
+    flex
+    items-center
+    justify-center
+    ${className}
+`;
+
+// ✅ Good — object property multiline uses template literal
+const variantClasses = {
+    danger: `
+        flex
+        items-center
+        justify-center
+        bg-red-500
+    `,
+};
+
+// ✅ Good — short class strings stay on one line
+<div className="flex items-center" />
+
+// ❌ Bad — too many classes on one line
+<div className="flex items-center justify-center rounded-lg p-4 font-bold" />
+
+// ❌ Bad — using template literal in JSX when no expressions
+<div className={`
+    flex
+    items-center
+    justify-center
+    rounded-lg
+`} />
+
+// ❌ Bad — empty lines between classes
+<div className="
+    flex
+
+    items-center
+    justify-center
+" />
+```
+
+---
+
+### `classname-no-extra-spaces`
+
+**What it does:** Removes multiple consecutive spaces and leading/trailing spaces inside className values. Applies to:
+- JSX `className` attributes (string literals and template literals)
+- Variables with names containing "class" (e.g., `buttonClasses`, `variantClasses`)
+- Object properties within class-related objects
+
+**Why use it:** Extra spaces between class names are usually unintentional and can cause issues. This rule normalizes spacing and removes unnecessary whitespace.
+
+```javascript
+// ✅ Good — single space between classes
+<div className="flex items-center gap-4 rounded-lg" />
+const buttonClasses = `flex items-center ${className}`;
+const variantClasses = { primary: "bg-blue-500 text-white" };
+
+// ❌ Bad — multiple consecutive spaces
+<div className="flex  items-center   gap-4" />
+const buttonClasses = `flex  items-center`;
+const variantClasses = { primary: "bg-blue-500  text-white" };
+
+// ❌ Bad — leading/trailing spaces in template literal
+const buttonClasses = ` flex items-center ${className} `;
+```
+
+---
+
 ### `jsx-children-on-new-line`
 
 **What it does:** When a JSX element has multiple children, ensures each child is on its own line with proper indentation.
@@ -2195,6 +2395,139 @@ const item = data[ index ];
 
 <br />
 
+## 🧩 Component Rules
+
+### `component-props-destructure`
+
+**What it does:** Enforces that React component props must be destructured in the function parameter, not received as a single `props` object.
+
+**Why use it:** Destructured props make it immediately clear what props a component uses. It improves readability and helps catch unused props.
+
+```typescript
+// ✅ Good — props are destructured
+export const Button = ({ label, onClick, variant = "primary" }) => (
+    <button onClick={onClick} type="button">
+        {label}
+    </button>
+);
+
+export const Card = ({
+    children,
+    className = "",
+    title,
+} : {
+    children: ReactNode,
+    className?: string,
+    title: string,
+}) => (
+    <div className={className}>
+        <h2>{title}</h2>
+        {children}
+    </div>
+);
+
+// ❌ Bad — props received as single object
+export const Button = (props) => (
+    <button onClick={props.onClick} type="button">
+        {props.label}
+    </button>
+);
+
+export const Card = (props: CardPropsInterface) => (
+    <div className={props.className}>
+        <h2>{props.title}</h2>
+        {props.children}
+    </div>
+);
+```
+
+---
+
+### `component-props-inline-type`
+
+**What it does:** Enforces that React component props must use inline type annotation instead of referencing an interface or type alias. Also enforces:
+- Exactly one space before and after colon: `} : {`
+- Props in type must match exactly with destructured props (no missing or extra)
+- Each prop type on its own line when there are multiple props
+- First prop type must be on new line after `{` when multiple props
+- No empty lines after opening brace or before closing brace
+- No space before `?` in optional properties (`prop?: type` not `prop ?: type`)
+- Trailing commas (not semicolons) for each prop type
+- No empty lines between prop types
+
+**Why use it:** Inline types keep the prop definitions colocated with the component, making it easier to understand and modify the component without jumping to separate interface definitions. Enforcing prop matching ensures type safety and prevents unused type properties.
+
+```typescript
+// ✅ Good — inline type annotation with matching props
+export const Button = ({ label } : { label: string }) => (
+    <button type="button">{label}</button>
+);
+
+export const Card = ({
+    className = "",
+    description,
+    title,
+} : {
+    className?: string,
+    description?: string,
+    title: string,
+}) => (
+    <div className={className}>
+        <h1>{title}</h1>
+        {description && <p>{description}</p>}
+    </div>
+);
+
+// ❌ Bad — interface reference instead of inline type
+interface ButtonPropsInterface {
+    label: string,
+}
+export const Button = ({ label }: ButtonPropsInterface) => (
+    <button type="button">{label}</button>
+);
+
+// ❌ Bad — missing space before and after colon
+export const Button = ({ label }:{ label: string }) => (
+    <button type="button">{label}</button>
+);
+
+// ❌ Bad — props don't match (extra 'flag' in type, missing in destructured)
+export const Card = ({
+    title,
+} : {
+    flag: boolean,
+    title: string,
+}) => (
+    <div>{title}</div>
+);
+
+// ❌ Bad — semicolons instead of commas
+export const Card = ({ title } : { title: string; }) => (
+    <div>{title}</div>
+);
+
+// ❌ Bad — first prop on same line as opening brace
+export const Card = ({
+    title,
+} : { title: string,
+    className?: string,
+}) => (
+    <div>{title}</div>
+);
+
+// ❌ Bad — space before ? in optional property
+export const Card = ({ title } : { title ?: string }) => (
+    <div>{title}</div>
+);
+
+// ❌ Bad — props on same line when multiple
+export const Card = ({ a, b } : { a: string, b: string }) => (
+    <div>{a}{b}</div>
+);
+```
+
+<br />
+
 ## 🔷 TypeScript Rules
 
 ### `enum-format`
@@ -2321,6 +2654,45 @@ export type ConfigType = {
 
 ---
 
+### `type-annotation-spacing`
+
+**What it does:** Enforces consistent spacing in TypeScript type annotations:
+- No space before the colon in type annotations: `name: string` not `name : string`
+- One space after the colon: `name: string` not `name:string`
+- No space before generic type parameters: `Array<T>` not `Array <T>`
+- No space before array brackets: `string[]` not `string []`
+
+**Why use it:** Consistent type annotation spacing follows TypeScript conventions and improves code readability.
+
+```typescript
+// ✅ Good — proper spacing
+const name: string = "John";
+const items: string[] = [];
+const data: Array<number> = [];
+const handler = (value: string): boolean => true;
+
+function getData<T>(id: string): Promise<T> {
+    return fetch(id);
+}
+
+// ❌ Bad — space before colon
+const name : string = "John";
+const handler = (value : string) : boolean => true;
+
+// ❌ Bad — no space after colon
+const name:string = "John";
+const handler = (value:string):boolean => true;
+
+// ❌ Bad — space before generic
+const data: Array <number> = [];
+function getData <T>(id: string): Promise <T> {}
+
+// ❌ Bad — space before array brackets
+const items: string [] = [];
+```
+
+---
+
 ### `typescript-definition-location`
 
 **What it does:** Enforces that TypeScript definitions are placed in their designated folders:
@@ -2368,13 +2740,184 @@ export enum StatusEnum {           // Should be in enums folder, not types
 
 <br />
 
+## ⚛️ React Rules
+
+### `react-code-order`
+
+**What it does:** Enforces a consistent ordering of code blocks within React components and custom hooks. The order follows a logical dependency chain where declarations appear before their usage.
+
+**Order (top to bottom):**
+1. Props/params destructure (in function signature: `({ prop1, prop2 })`)
+2. Props/params destructure in body (`const { x } = propValue` where propValue is a prop)
+3. `useRef` declarations
+4. `useState` declarations
+5. `useReducer` declarations
+6. `useSelector` / `useDispatch` (Redux hooks)
+7. Router hooks (`useNavigate`, `useLocation`, `useParams`, `useSearchParams`)
+8. Context hooks (`useContext`, `useToast`, etc.)
+9. Custom hooks (`use*` pattern)
+10. Derived state / variables (computed from hooks above, e.g., `const isSearching = term.length > 0`)
+11. `useMemo` declarations
+12. `useCallback` declarations
+13. Handler functions (`const handleX = () => {}`)
+14. `useEffect` / `useLayoutEffect`
+15. Return statement
+
+**Why use it:** A consistent code structure makes components and hooks predictable and easier to navigate. Placing hooks before derived values ensures dependencies are defined before use. Effects come last because they typically depend on everything else.
+
+```typescript
+// ✅ Good — Component follows the correct order
+const UserDashboard = ({ title }) => {
+    // 1. useRef
+    const inputRef = useRef(null);
+
+    // 2. useState
+    const [count, setCount] = useState(0);
+    const [isLoading, setIsLoading] = useState(false);
+
+    // 3. Redux hooks
+    const dispatch = useDispatch();
+    const user = useSelector((state) => state.user);
+
+    // 4. Router hooks
+    const navigate = useNavigate();
+    const { id } = useParams();
+
+    // 5. Custom hooks
+    const { data, loading } = useFetchData(id);
+
+    // 6. Derived state
+    const isReady = !loading && data !== null;
+    const displayName = user?.name ?? "Guest";
+
+    // 7. useMemo
+    const filteredItems = useMemo(
+        () => data?.filter((item) => item.active),
+        [data],
+    );
+
+    // 8. useCallback
+    const handleSubmit = useCallback(
+        () => {
+            dispatch(submitAction());
+        },
+        [dispatch],
+    );
+
+    // 9. Handler functions
+    const resetHandler = () => {
+        setCount(0);
+        setIsLoading(false);
+    };
+
+    // 10. useEffect
+    useEffect(
+        () => {
+            inputRef.current?.focus();
+        },
+        [],
+    );
+
+    // 11. Return
+    return (
+        <div>
+            <h1>{title}</h1>
+            <span>{displayName}</span>
+        </div>
+    );
+};
+
+// ✅ Good — Custom hook follows the correct order
+const useCreateAccount = () => {
+    // 1. useState
+    const [loading, setLoading] = useState(false);
+    const [created, setCreated] = useState(false);
+
+    // 2. Redux hooks
+    const dispatch = useDispatch();
+
+    // 3. Context hooks
+    const { toast } = useToast();
+
+    // 4. Handler functions
+    const createAccountHandler = async (data: AccountData) => {
+        setLoading(true);
+        try {
+            await api.createAccount(data);
+            setCreated(true);
+        } catch (error) {
+            toast({ description: "Failed to create account" });
+        } finally {
+            setLoading(false);
+        }
+    };
+
+    // 5. useEffect
+    useEffect(
+        () => {
+            if (created) {
+                setTimeout(() => setCreated(false), 50);
+            }
+        },
+        [created],
+    );
+
+    // 6. Return
+    return { createAccountHandler, created, loading };
+};
+
+// ❌ Bad — useEffect before useState
+const BadComponent = ({ title }) => {
+    useEffect(() => {
+        console.log("mounted");
+    }, []);
+
+    const [count, setCount] = useState(0);
+
+    return <div>{title}</div>;
+};
+
+// ❌ Bad — context hook before useState in custom hook
+const useBadHook = () => {
+    const { toast } = useToast();          // Should come after useState
+    const [loading, setLoading] = useState(false);
+    return { loading };
+};
+
+// ❌ Bad — handler before hooks
+const AnotherBadComponent = ({ title }) => {
+    const handleClick = () => {
+        console.log("clicked");
+    };
+
+    const dispatch = useDispatch();
+    const [count, setCount] = useState(0);
+
+    return <div onClick={handleClick}>{title}</div>;
+};
+
+// ❌ Bad — derived state after handler
+const YetAnotherBad = ({ title }) => {
+    const [items, setItems] = useState([]);
+
+    const handleAdd = () => {
+        setItems([...items, "new"]);
+    };
+
+    const itemCount = items.length; // Should come before handleAdd
+
+    return <div>{itemCount}</div>;
+};
+```
+
+<br />
+
 ## 📝 Variable Rules
 
 ### `variable-naming-convention`
 
 **What it does:** Enforces naming conventions for variables:
-- **camelCase** for regular variables and functions
-- **UPPER_CASE** for constants (primitive values)
+- **camelCase** for all variables and constants
 - **PascalCase** for React components and classes
 - **camelCase with `use` prefix** for hooks
 
@@ -2384,14 +2927,14 @@ export enum StatusEnum {           // Should be in enums folder, not types
 // ✅ Good — correct conventions
 const userName = "John";           // camelCase for variables
 const itemCount = 42;              // camelCase for variables
-const MAX_RETRIES = 3;             // UPPER_CASE for constants
-const API_BASE_URL = "/api";       // UPPER_CASE for constants
+const maxRetries = 3;              // camelCase for constants
+const apiBaseUrl = "/api";         // camelCase for constants
 const UserProfile = () => <div />; // PascalCase for components
 const useAuth = () => {};          // camelCase with use prefix for hooks
 
 // ❌ Bad — wrong conventions
 const user_name = "John";          // snake_case
-const maxretries = 3;              // should be UPPER_CASE
+const MAX_RETRIES = 3;             // should be camelCase
 const userProfile = () => <div />; // should be PascalCase
 const UseAuth = () => {};          // hooks should be camelCase
 ```