eslint-plugin-code-style 1.7.4 → 1.8.1

package/CHANGELOG.md

@@ -7,6 +7,58 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ---
 
+## [1.8.1] - 2026-02-03
+
+### Changed
+
+- **`function-naming-convention`** - Add `handleXxx` → `xxxHandler` auto-fix (converts `handleClick` to `clickHandler` instead of `handleClickHandler`)
+
+---
+
+## [1.8.0] - 2026-02-03
+
+### Added
+
+- **New Rule: `no-hardcoded-strings`** - Enforce importing strings from constants/strings modules instead of hardcoding them inline. Promotes maintainability, consistency, and easier internationalization.
+  - Detects hardcoded strings in JSX text content, attributes, and component logic
+  - Configurable `ignoreAttributes`, `extraIgnoreAttributes`, `ignorePatterns` options
+  - Automatically ignores technical strings (CSS units, URLs, paths, identifiers, etc.)
+  - Valid import paths: `@/constants`, `@/strings`, `@/@constants`, `@/@strings`, `@/data/constants`, `@/data/strings`
+
+### Changed
+
+- **`absolute-imports-only`** - Add `strings`, `@constants`, `@strings` to default allowed folders
+- **`module-index-exports`** - Add `strings`, `@constants`, `@strings` to default module folders
+
+### Stats
+
+- Total Rules: 70 (was 69)
+- Auto-fixable: 63 rules 🔧
+- Report-only: 7 rules (was 6)
+
+---
+
+## [1.7.6] - 2026-02-02
+
+### Changed
+
+- **`ternary-condition-multiline`** - Now depends only on operand count, not line length:
+  - ≤maxOperands (default: 3): Always collapse to single line regardless of line length
+  - \>maxOperands: Format multiline with each operand on its own line
+  - Removed `maxLineLength` option (no longer used)
+  - This aligns behavior with `multiline-if-conditions` rule
+
+---
+
+## [1.7.5] - 2026-02-02
+
+### Fixed
+
+- **`ternary-condition-multiline`** - For ≤3 operands, always collapse to single line when `?` is on different line than condition end (enforces `condition ? value : value` format for simple ternaries)
+- **`no-empty-lines-in-function-params`** - Add detection for empty lines in TSTypeLiteral (type annotation objects like `{ prop: Type }` in intersection types)
+
+---
+
 ## [1.7.4] - 2026-02-02
 
 ### Fixed
@@ -1117,6 +1169,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ---
 
+[1.8.1]: https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/compare/v1.8.0...v1.8.1
+[1.8.0]: https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/compare/v1.7.6...v1.8.0
+[1.7.6]: https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/compare/v1.7.5...v1.7.6
+[1.7.5]: https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/compare/v1.7.4...v1.7.5
 [1.7.4]: https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/compare/v1.7.3...v1.7.4
 [1.7.3]: https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/compare/v1.7.2...v1.7.3
 [1.7.2]: https://github.com/Mohamed-Elhawary/eslint-plugin-code-style/compare/v1.7.1...v1.7.2

package/README.md

@@ -19,7 +19,7 @@
 
 **A powerful ESLint plugin for enforcing consistent code formatting and style rules in React/JSX projects.**
 
-*69 rules (63 auto-fixable) to keep your codebase clean and consistent*
+*70 rules (63 auto-fixable) to keep your codebase clean and consistent*
 
 </div>
 
@@ -27,7 +27,7 @@
 
 ## 🎯 Why This Plugin?
 
-This plugin provides **69 custom rules** (63 auto-fixable) for code formatting. Built for **ESLint v9 flat configs**.
+This plugin provides **70 custom rules** (63 auto-fixable) 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.
 
@@ -36,7 +36,7 @@ This plugin provides **69 custom rules** (63 auto-fixable) for code formatting.
 - **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
-- **Highly automated** — 63 of 69 rules support auto-fix with `eslint --fix`
+- **Highly automated** — 63 of 70 rules support auto-fix with `eslint --fix`
 
 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.
 
@@ -236,6 +236,7 @@ rules: {
     "code-style/no-empty-lines-in-jsx": "error",
     "code-style/no-empty-lines-in-objects": "error",
     "code-style/no-empty-lines-in-switch-cases": "error",
+    "code-style/no-hardcoded-strings": "error",
     "code-style/no-inline-type-definitions": "error",
     "code-style/object-property-per-line": "error",
     "code-style/object-property-value-brace": "error",
@@ -259,7 +260,7 @@ rules: {
 
 ## 📖 Rules Categories
 
-> **69 rules total** — 63 with auto-fix 🔧, 6 report-only. See detailed examples in [Rules Reference](#-rules-reference) below.
+> **70 rules total** — 63 with auto-fix 🔧, 7 report-only. See detailed examples in [Rules Reference](#-rules-reference) below.
 >
 > **Legend:** 🔧 Auto-fixable with `eslint --fix` • ⚙️ Customizable options
 
@@ -295,11 +296,11 @@ rules: {
 | `if-statement-format` | `{` on same line as `if`/`else if`, `else` on same line as `}`, proper spacing 🔧 |
 | `multiline-if-conditions` | Conditions exceeding threshold get one operand per line with proper indentation (default: >3) 🔧 ⚙️ |
 | `no-empty-lines-in-switch-cases` | No empty line after `case X:` before code, no empty lines between cases 🔧 |
-| `ternary-condition-multiline` | Collapse simple ternaries to single line; expand complex conditions (>3 operands) to multiline 🔧 ⚙️ |
+| `ternary-condition-multiline` | ≤maxOperands always single line; >maxOperands multiline (based on operand count, not line length) 🔧 ⚙️ |
 | **Function Rules** | |
 | `function-call-spacing` | No space between function name and `(`: `fn()` not `fn ()` 🔧 |
 | `function-declaration-style` | Auto-fix for `func-style`: converts function declarations to arrow expressions 🔧 |
-| `function-naming-convention` | Functions use camelCase, start with verb (get/set/handle/is/has), handlers end with Handler 🔧 |
+| `function-naming-convention` | Functions use camelCase, start with verb, end with Handler suffix; handleXxx → xxxHandler 🔧 |
 | `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 `)` 🔧 |
@@ -348,6 +349,8 @@ rules: {
 | `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 🔧 |
+| **String Rules** | |
+| `no-hardcoded-strings` | Enforce importing strings from constants/strings modules instead of hardcoding them ⚙️ |
 | **Variable Rules** | |
 | `variable-naming-convention` | camelCase for all variables and constants, PascalCase for components, `use` prefix for hooks 🔧 |
 
@@ -1211,24 +1214,24 @@ switch (status) {
 
 ### `ternary-condition-multiline`
 
-**What it does:** Enforces consistent ternary formatting:
-- Simple ternaries (≤3 operands in condition) collapse to single line if they fit
-- Complex ternaries (>3 operands) expand to multiline with each operand on its own line
+**What it does:** Formats ternary expressions based on condition operand count:
+- ≤maxOperands (default: 3): Always collapse to single line regardless of line length
+- \>maxOperands: Expand to multiline with each operand on its own line
 
-**Why use it:** Long ternary conditions on a single line are hard to read. Breaking complex conditions into multiple lines makes them scannable.
+**Why use it:** Consistent formatting based on complexity, not line length. Simple conditions stay readable on one line; complex conditions get proper multiline formatting.
 
 **Options:**
 
 | Option | Type | Default | Description |
 |--------|------|---------|-------------|
-| `maxOperands` | `integer` | `3` | Maximum operands to keep on single line |
-| `maxLineLength` | `integer` | `120` | Maximum line length for single-line ternaries |
+| `maxOperands` | `integer` | `3` | Maximum condition operands to keep ternary on single line |
 
 ```javascript
-// ✅ Good — simple condition on single line
+// ✅ Good — ≤3 operands always on single line
 const x = a && b && c ? "yes" : "no";
+const url = lang === "ar" ? `${apiEndpoints.exam.status}/${jobId}?lang=ar` : `${apiEndpoints.exam.status}/${jobId}`;
 
-// ✅ Good — complex condition multiline (>3 operands)
+// ✅ Good — >3 operands formatted multiline
 const style = variant === "ghost"
     || variant === "ghost-danger"
     || variant === "muted"
@@ -1236,7 +1239,12 @@ const style = variant === "ghost"
     ? "transparent"
     : "solid";
 
-// ❌ Bad — complex condition crammed on one line
+// ❌ Bad — ≤3 operands split across lines
+const x = a && b && c
+    ? "yes"
+    : "no";
+
+// ❌ Bad — >3 operands crammed on one line
 const style = variant === "ghost" || variant === "ghost-danger" || variant === "muted" || variant === "primary" ? "transparent" : "solid";
 ```
 
@@ -1311,33 +1319,37 @@ function isAuthenticated(): boolean {
 
 **What it does:** Enforces naming conventions for functions:
 - **camelCase** required
-- **Verb prefix** recommended (get, set, handle, is, has, can, should, etc.)
-- **Event handlers** can use `handle` prefix or `Handler` suffix
+- **Verb prefix** required (get, set, fetch, is, has, can, should, click, submit, etc.)
+- **Handler suffix** required (all functions must end with `Handler`)
+- **Auto-fixes** `handleXxx` to `xxxHandler` (avoids redundant `handleClickHandler`)
+- **Auto-fixes** PascalCase to camelCase for verb-prefixed functions
 
-**Why use it:** Function names should describe actions. Verb prefixes make the purpose immediately clear.
+**Why use it:** Function names should describe actions. Verb prefixes make the purpose immediately clear, and consistent Handler suffix makes event handlers easy to identify.
 
 ```javascript
-// ✅ Good — clear verb prefixes
-function getUserData() {}
-function setUserName(name) {}
-function handleClick() {}
-function handleSubmit() {}
-function isValidEmail(email) {}
-function hasPermission(user) {}
-function canAccess(resource) {}
-function shouldUpdate(props) {}
-const fetchUsers = async () => {};
-const submitHandler = () => {};
+// ✅ Good — verb prefix + Handler suffix
+function getUserDataHandler() {}
+function setUserNameHandler(name) {}
+function clickHandler() {}
+function submitHandler() {}
+function isValidEmailHandler(email) {}
+function hasPermissionHandler(user) {}
+function canAccessHandler(resource) {}
+const fetchUsersHandler = async () => {};
+
+// ❌ Bad (auto-fixed) — handleXxx → xxxHandler
+function handleClick() {}    // → clickHandler
+function handleSubmit() {}   // → submitHandler
+function handleChange() {}   // → changeHandler
 
-// ❌ Bad — no verb, unclear purpose
-function userData() {}
-function userName(name) {}
-function click() {}
-function valid(email) {}
+// ❌ Bad (auto-fixed) — missing Handler suffix
+function getUserData() {}    // → getUserDataHandler
+function setUserName() {}    // → setUserNameHandler
+function fetchUsers() {}     // → fetchUsersHandler
 
-// ❌ Bad — wrong case
-function GetUserData() {}
-function get_user_data() {}
+// ❌ Bad (auto-fixed) — PascalCase to camelCase
+function GetUserData() {}    // → getUserDataHandler
+function FetchStatus() {}    // → fetchStatusHandler
 ```
 
 ---
@@ -3273,6 +3285,73 @@ const YetAnotherBad = ({ title }) => {
 
 <br />
 
+## 📝 String Rules
+
+### `no-hardcoded-strings`
+
+**What it does:** Enforces that user-facing strings should be imported from constants/strings modules rather than hardcoded inline. This promotes maintainability, consistency, and enables easier internationalization.
+
+**Why use it:** Hardcoded strings scattered throughout your codebase are hard to maintain, translate, and keep consistent. Centralizing strings in constants makes them easy to find, update, and potentially translate.
+
+**Options:**
+
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| `ignoreAttributes` | `string[]` | See below | JSX attributes to ignore (replaces defaults) |
+| `extraIgnoreAttributes` | `string[]` | `[]` | Additional JSX attributes to ignore (extends defaults) |
+| `ignorePatterns` | `string[]` | `[]` | Regex patterns for strings to ignore |
+
+**Default ignored attributes:** `className`, `id`, `type`, `name`, `href`, `src`, `alt`, `role`, `style`, `key`, `data-*`, `aria-*`, and many more HTML/SVG attributes.
+
+**Default ignored patterns:** Empty strings, single characters, CSS units (`px`, `em`, `%`), colors, URLs, paths, file extensions, MIME types, UUIDs, dates, camelCase/snake_case identifiers, HTTP methods, and other technical strings.
+
+```javascript
+// ✅ Good — strings imported from constants
+import { BUTTON_LABEL, ERROR_MESSAGE, welcomeText } from "@/constants";
+import { FORM_LABELS } from "@/strings";
+
+const Component = () => (
+    <div>
+        <button>{BUTTON_LABEL}</button>
+        <span>{ERROR_MESSAGE}</span>
+        <p>{welcomeText}</p>
+    </div>
+);
+
+const getMessage = () => ERROR_MESSAGE;
+
+// ✅ Good — technical strings are allowed
+<input type="text" className="input-field" />
+<a href="/dashboard">Link</a>
+const url = `/api/users/${id}`;
+const size = "100px";
+
+// ❌ Bad — hardcoded user-facing strings
+<button>Submit Form</button>
+<span>Something went wrong</span>
+const message = "Welcome to the application";
+return "User not found";
+```
+
+**Configuration example:**
+
+```javascript
+// Allow more attributes, add custom ignore patterns
+"code-style/no-hardcoded-strings": ["error", {
+    extraIgnoreAttributes: ["tooltip", "placeholder"],
+    ignorePatterns: ["^TODO:", "^FIXME:"]
+}]
+```
+
+**Valid import paths for constants:**
+- `@/constants` or `@/@constants`
+- `@/strings` or `@/@strings`
+- `@/data/constants` or `@/data/strings`
+
+---
+
+<br />
+
 ## 📝 Variable Rules
 
 ### `variable-naming-convention`
@@ -3306,7 +3385,7 @@ const UseAuth = () => {};          // hooks should be camelCase
 
 ## 🔧 Auto-fixing
 
-63 of 69 rules support auto-fixing. Run ESLint with the `--fix` flag:
+63 of 70 rules support auto-fixing. Run ESLint with the `--fix` flag:
 
 ```bash
 # Fix all files in src directory

package/index.d.ts

@@ -59,6 +59,7 @@ export type RuleNames =
     | "code-style/no-empty-lines-in-jsx"
     | "code-style/no-empty-lines-in-objects"
     | "code-style/no-empty-lines-in-switch-cases"
+    | "code-style/no-hardcoded-strings"
     | "code-style/object-property-per-line"
     | "code-style/object-property-value-brace"
     | "code-style/object-property-value-format"
@@ -150,6 +151,7 @@ interface PluginRules {
     "no-empty-lines-in-jsx": Rule.RuleModule;
     "no-empty-lines-in-objects": Rule.RuleModule;
     "no-empty-lines-in-switch-cases": Rule.RuleModule;
+    "no-hardcoded-strings": Rule.RuleModule;
     "object-property-per-line": Rule.RuleModule;
     "object-property-value-brace": Rule.RuleModule;
     "object-property-value-format": Rule.RuleModule;