ESLint Plugin Code Style




A powerful ESLint plugin for enforcing consistent code formatting and style rules in React/JSX projects.

79 rules (70 auto-fixable, 19 configurable) to keep your codebase clean and consistent

Installation •
Quick Start •
Recommended Configs •
Rules •
Contributing

// ❌ Bad — extra parentheses not needed
const Icon = () => (

);
`

---

$3

What it does: Converts arrow functions with a single return statement to use implicit return, removing the block body and return keyword.

Why use it: Implicit returns are more concise and idiomatic JavaScript. They reduce noise and make the code easier to read.

`javascript
// ✅ Good — implicit return
const double = (x) => x * 2;
const getName = (user) => user.name;
const items = data.map((item) => item.value);
const isValid = (x) => x > 0 && x < 100;

// ❌ Bad — unnecessary block body and return
const double = (x) => { return x * 2; };
const getName = (user) => { return user.name; };
const items = data.map((item) => { return item.value; });
const isValid = (x) => { return x > 0 && x < 100; };
`

---

$3

What it does: Ensures that when an arrow function returns another function, the returned function starts on the same line as =>.

Why use it: Curried functions are easier to read when the chain is visible. Breaking after => obscures the function structure.

`javascript
// ✅ Good — curried function visible on same line
const createAction = (type) => (payload) => ({ type, payload });

const withLogger = (fn) => (...args) => {
console.log("Called with:", args);
return fn(...args);
};

const mapDispatch = () => async (dispatch) => {
await dispatch(fetchData());
};

// ❌ Bad — chain broken across lines
const createAction = (type) =>
(payload) => ({ type, payload });

const mapDispatch = () =>
async (dispatch) => {
await dispatch(fetchData());
};
`

📞 Call Expression Rules

$3

What it does: Enforces consistent formatting for function call arguments:
- Single simple argument stays on one line
- 2+ arguments get one per line
- Multiline arguments trigger full expansion
- React hooks are skipped by default (they have their own rule)

Why use it: Consistent argument formatting makes function calls scannable and diffs clean when adding/removing arguments.

`javascript
// ✅ Good — single argument stays compact
fetchUser(userId);
console.log(message);
dispatch(action);

// ✅ Good — 2+ arguments get one per line
setValue(
"email",
"user@example.com",
);

createUser(
name,
email,
password,
);

// ✅ Good — multiline argument triggers expansion
processData(
{
id: 1,
name: "test",
},
);

// ✅ Good — callback with body triggers expansion
items.forEach(
(item) => {
process(item);
save(item);
},
);

// ❌ Bad — multiple arguments on same line
setValue("email", "user@example.com");
createUser(name, email, password);

// ❌ Bad — inconsistent formatting
fn(arg1,
arg2, arg3);
`

Options:

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| minArgs | integer | 2 | Minimum arguments to enforce multiline |
| skipHooks | boolean | true | Skip React hooks (useEffect, etc.) |
| skipSingleArg | boolean | true | Skip calls with single complex argument |

`javascript
// Example: Require multiline for 3+ arguments
"code-style/function-arguments-format": ["error", { minArgs: 3 }]

// Example: Don't skip React hooks
"code-style/function-arguments-format": ["error", { skipHooks: false }]
`

---

$3

What it does: Ensures nested function calls (common in styled-components, HOCs) have closing brackets on the same line: }));

Why use it: Scattered closing brackets (}\n);\n ) waste vertical space and make it harder to see where expressions end.

`javascript
// ✅ Good — closing brackets together
const StyledCard = styled(Card)(({ theme }) => ({
color: theme.palette.text.primary,
padding: theme.spacing(2),
}));

const StyledButton = styled("button")(({ theme }) => ({
backgroundColor: theme.colors.primary,
}));

// ✅ Good — multiple levels
const Component = connect(
mapStateToProps,
mapDispatchToProps,
)(withRouter(MyComponent));

// ❌ Bad — closing brackets scattered
const StyledCard = styled(Card)(({ theme }) => ({
color: theme.palette.text.primary,
})
);

// ❌ Bad — each bracket on its own line
const StyledCard = styled(Card)(({ theme }) => ({
color: theme.colors.primary,
})
)
;
`

---

$3

What it does: Removes empty lines within function call argument lists — between arguments and after opening/before closing parentheses.

Why use it: Empty lines between arguments break visual grouping. Arguments should flow as a cohesive list.

`javascript
// ✅ Good — no empty lines
createUser(
name,
email,
password,
role,
);

fetchData(
url,
{
method: "POST",
body: data,
},
);

// ❌ Bad — empty line between arguments
createUser(
name,

email,

password,
);

// ❌ Bad — empty line after opening paren
fetchData(

url,
options,
);

// ❌ Bad — empty line before closing paren
fetchData(
url,
options,

);
`

---

$3

What it does: Ensures opening brackets ({, [, () in function arguments stay on the same line as the function call.

Why use it: Opening brackets on new lines create unnecessary indentation and vertical space.

`javascript
// ✅ Good — brackets on same line as call
fn({ key: value });
process([1, 2, 3]);
items.map(({ id }) => id);
configure({ debug: true });

// ✅ Good — multiline content is fine
fn({
key: value,
other: data,
});

items.map(({ id, name }) => (

));

// ❌ Bad — opening bracket on new line
fn(
{ key: value }
);

process(
[1, 2, 3]
);

items.map(
({ id }) => id
);
`

---

$3

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(...)) 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"));
setTimeout(() => callback(), 100);
const symbol = items.find(({ code }) => code === currency)?.symbol;

// ✅ Good — complex callbacks stay multiline
const Page = lazy(() => {
console.log("Loading page");
return import("./Page");
});

// ❌ Bad — unnecessary multiline for simple pattern
const Page = lazy(
() => import("./Page"),
);

const symbol = items.find(({ code }) =>
code === currency)?.symbol;

const symbol = items.find(({ code }) => code === currency)?.
symbol;
`

---

$3

What it does: Ensures function calls with a single simple argument (literal, identifier, member expression) stay on one line.

Why use it: Single-argument calls don't need multiline formatting. Expanding them wastes vertical space.

`javascript
// ✅ Good — single argument on one line
fetchUser(userId);
console.log(message);
process(data.items);
dispatch(action);
setValue("key");
getElement(document.body);

// ✅ Good — complex single argument can be multiline
processConfig({
key: value,
other: data,
});

// ❌ Bad — simple argument expanded unnecessarily
fetchUser(
userId,
);

console.log(
message,
);

dispatch(
action,
);
`

💬 Comment Rules

$3

What it does: Enforces proper comment formatting:
- Space after // in line comments
- Space after / and before / in block comments
- Single-line block comments converted to line comments
- No blank lines between consecutive comments at file top

Why use it: Consistent comment formatting improves readability and maintains a clean, professional codebase.

`javascript
// ✅ Good — proper spacing
// This is a comment
/ This is a block comment /

/*
* This is a multi-line
* block comment
*/

// ✅ Good — file-top comments without gaps
// File: utils.js
// Author: John Doe
// License: MIT

// ❌ Bad — missing space after //
//This is a comment

// ❌ Bad — no space in block comment
/No space/

// ❌ Bad — single-line block should be line comment
/ This should use // syntax /
`

🏛️ Class Rules

$3

What it does: Enforces consistent spacing in class and method definitions:
- Space before opening brace { in class declarations
- No space between method name and opening parenthesis (
- Space before opening brace { in method definitions
- Opening brace must be on same line as class/method signature

Why use it: Consistent formatting makes code more readable and prevents common spacing inconsistencies in class definitions.

`javascript
// ✅ Good — proper spacing in class and methods
class ApiServiceClass {
getDataHandler(): string {
return "data";
}

async fetchUserHandler(id: string): Promise {
return await this.fetch(id);
}
}

// ❌ Bad — missing space before { in class
class ApiServiceClass{
getDataHandler(): string {
return "data";
}
}

// ❌ Bad — space between method name and (
class ApiServiceClass {
getDataHandler (): string {
return "data";
}
}

// ❌ Bad — missing space before { in method
class ApiServiceClass {
getDataHandler(): string{
return "data";
}
}

// ❌ Bad — opening brace on different line
class ApiServiceClass {
getDataHandler(): string
{
return "data";
}
}
`

---

$3

What it does: Enforces that class declarations must end with "Class" suffix. This distinguishes class definitions from other PascalCase names like React components or type definitions.

Why use it: Clear naming conventions prevent confusion between classes, components, and types. The "Class" suffix immediately identifies the construct.

`javascript
// ✅ Good — class ends with "Class"
class ApiServiceClass {
constructor() {}
fetch() {}
}

class UserRepositoryClass {
save(user) {}
}

// ❌ Bad — missing "Class" suffix
class ApiService {
constructor() {}
}

class UserRepository {
save(user) {}
}
`

🔀 Control Flow Rules

$3

What it does: Enforces newlines after the opening brace { and before the closing brace } in block statements (if, for, while, etc.).

Why use it: Consistent block formatting improves readability. Single-line blocks are harder to scan and edit.

`javascript
// ✅ Good — proper block formatting
if (condition) {
doSomething();
}

for (const item of items) {
process(item);
}

while (running) {
tick();
}

// ❌ Bad — everything on one line
if (condition) { doSomething(); }

// ❌ Bad — no space after brace
if (condition) {doSomething();}

// ❌ Bad — inconsistent formatting
for (const item of items) { process(item);
}
`

---

$3

What it does: Requires an empty line between a closing brace } of a block statement (if, try, for, while, etc.) and the next statement, unless the next statement is part of the same construct (else, catch, finally).

Why use it: Visual separation between logical blocks improves code readability and makes the structure clearer.

> Note: Consecutive if statements are handled by if-else-spacing rule.

`javascript
// ✅ Good — empty line after block
if (condition) {
doSomething();
}

const x = 1;

// ✅ Good — else is part of same construct (no empty line needed)
if (condition) {
doSomething();
} else {
doOther();
}

// ❌ Bad — no empty line after block
if (condition) {
doSomething();
}
const x = 1;
`

---

$3

What it does: Enforces proper spacing between if statements and if-else chains:
- Consecutive if statements with block bodies must have an empty line between them
- Single-line if and else should NOT have empty lines between them

Why use it: Maintains visual separation between distinct conditional blocks while keeping related single-line if-else pairs compact.

`javascript
// ✅ Good — empty line between consecutive if blocks
if (!hasValidParams) return null;

if (status === "loading") {
return ;
}

if (status === "error") {
return ;
}

// ✅ Good — no empty line between single-line if-else
if (error) prom.reject(error);
else prom.resolve(token);

// ❌ Bad — no empty line between if blocks
if (!hasValidParams) return null;
if (status === "loading") {
return ;
}
if (status === "error") {
return ;
}

// ❌ Bad — empty line between single-line if-else
if (error) prom.reject(error);

else prom.resolve(token);
`

---

$3

What it does: Enforces consistent if/else formatting:
- Opening { on the same line as if/else if/else
- else on the same line as the closing }
- Proper spacing around keywords

Why use it: Consistent brace placement reduces visual noise and follows the most common JavaScript style (K&R / "one true brace style").

`javascript
// ✅ Good — consistent formatting
if (condition) {
doSomething();

doMore();
}

if (condition) {
doSomething();

doMore();
} else {
doOther();

doAnother();
}

if (conditionA) {
handleA();

processA();
} else if (conditionB) {
handleB();

processB();
} else {
handleDefault();

processDefault();
}

// ❌ Bad — brace on new line
if (condition)
{
doSomething();

doMore();
}

// ❌ Bad — else on new line
if (condition) {
doSomething();

doMore();
}
else {
doOther();

doAnother();
}

// ❌ Bad — inconsistent formatting
if (condition)
{
doSomething();

doMore();
}
else
{
doOther();

doAnother();
}
`

---

$3

What it does: When a logical expression (&&, ||) has more operands than the threshold (default: 3), each operand goes on its own line with the operator at the start.

Why use it: Long logical expressions are hard to read on one line. One operand per line makes each part clear and easy to modify.

`javascript
// ✅ Good — 3 or fewer operands stay inline
const isValid = a && b && c;
const result = x || y;

// ✅ Good — 4+ operands get one per line
const err = data.error
|| data.message
|| data.status
|| data.fallback;

const isComplete = hasName
&& hasEmail
&& hasPhone
&& hasAddress;

// ❌ Bad — 4+ operands on single line
const err = data.error || data.message || data.status || data.fallback;
`

Options:

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| maxOperands | integer | 3 | Maximum operands allowed on a single line |

`javascript
// Configuration example - allow up to 4 operands on single line
"code-style/logical-expression-multiline": ["error", { maxOperands: 4 }]
`

---

$3

What it does: When an if statement has more conditions than the threshold (default: 3), each condition goes on its own line with proper indentation.

Why use it: Long conditions are hard to read on one line. One per line makes each condition clear and easy to modify.

`javascript
// ✅ Good — 3 or fewer conditions stay inline
if (isValid && isActive) {}
if (a && b && c) {}

// ✅ Good — 4+ conditions get one per line
if (
isAuthenticated &&
hasPermission &&
!isExpired &&
isEnabled
) {
allowAccess();
}

if (
user.isAdmin ||
user.isModerator ||
user.hasSpecialAccess ||
isPublicResource
) {
showContent();
}

// ❌ Bad — too many conditions on one line
if (isAuthenticated && hasPermission && !isExpired && isEnabled) {}

// ❌ Bad — inconsistent formatting
if (isAuthenticated &&
hasPermission && !isExpired &&
isEnabled) {}
`

Options:

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| maxOperands | integer | 3 | Maximum operands to keep on single line. Also applies to nested groups |

`javascript
// Example: Allow up to 4 operands on single line
"code-style/multiline-if-conditions": ["error", { maxOperands: 4 }]
`

Auto-formatting: Nested groups with >maxOperands are formatted multiline inline:

`javascript
// ❌ Before (nested group has 4 operands)
if ((a || b || c || d) && e) {}

// ✅ After auto-fix — formats nested group multiline
if ((
a
|| b
|| c
|| d
) && e) {}
`

Double nesting: Both levels expand when both exceed maxOperands:

`javascript
// ❌ Before (both parent and nested have 4 operands)
if ((a || (c && d && a && b) || c || d) && e) {}

// ✅ After auto-fix — both levels formatted multiline
if ((
a
|| (
c
&& d
&& a
&& b
)
|| c
|| d
) && e) {}
`

Extraction: Groups exceeding nesting level 2 are extracted to variables:

`javascript
// ❌ Before (level 3 nesting)
if ((a && (b || (c && d))) || e) {}

// ✅ After auto-fix — extracts deepest nested group
const isCAndD = (c && d);
if ((a && (b || isCAndD)) || e) {}
`

---

$3

What it does: Removes empty lines at the start of case blocks and between consecutive case statements.

Why use it: Empty lines inside switch cases create unnecessary gaps. Cases should flow together as a cohesive block.

`javascript
// ✅ Good — no empty lines
switch (status) {
case "pending":
return "Waiting...";
case "success":
return "Done!";
case "error":
return "Failed";
default:
return "Unknown";
}

// ✅ Good — fall-through cases grouped
switch (day) {
case "Saturday":
case "Sunday":
return "Weekend";
default:
return "Weekday";
}

// ❌ Bad — empty line after case label
switch (status) {
case "pending":

return "Waiting...";
case "success":
return "Done!";
}

// ❌ Bad — empty lines between cases
switch (status) {
case "pending":
return "Waiting...";

case "success":
return "Done!";

default:
return "Unknown";
}
`

---

$3

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
- Simple parenthesized nested ternaries (≤maxOperands) count as 1 operand and collapse
- Complex nested ternaries (>maxOperands in their condition) are skipped for manual formatting
- Nesting level is fixed at 2 to prevent overly complex conditions

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 condition operands to keep ternary on single line. Also applies to nested groups |

`javascript
// ✅ 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 — parenthesized nested ternary counts as 1 operand
const inputType = showToggle ? (showPassword ? "text" : "password") : type;

// ✅ Good — >3 operands formatted multiline
const style = variant === "ghost"
|| variant === "ghost-danger"
|| variant === "muted"
|| variant === "primary"
? "transparent"
: "solid";

// ✅ Good — nested group with >3 operands formatted multiline inline
const result = (
a
|| (
c
&& d
&& a
&& b
)
|| c
|| d
) && e ? "yes" : "no";

// ❌ 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";
`

Auto-extraction: Nested groups are auto-extracted to variables only when nesting depth exceeds 2 levels:

`javascript
// ❌ Before (level 3 nesting exceeds limit)
const result = (a && (b || (c && d))) || e ? "yes" : "no";

// ✅ After auto-fix — extracts deepest nested group
const isCAndD = (c && d);
const result = (a && (b || isCAndD)) || e ? "yes" : "no";
`

Note: When nested groups exceed maxOperands but stay within the 2-level nesting limit, they are formatted multiline inline (not extracted).

⚡ Function Rules

$3

What it does: Removes any space between a function name and its opening parenthesis.

Why use it: Standard JavaScript convention. fn() is correct, fn () looks like a typo and can cause confusion.

`javascript
// ✅ Good — no space before parenthesis
useDispatch();
myFunction(arg);
console.log("message");
array.map((x) => x * 2);
obj.method();

// ❌ Bad — space before parenthesis
useDispatch ();
myFunction (arg);
console.log ("message");
array.map ((x) => x * 2);
`

---

$3

What it does: Converts function declarations to const arrow function expressions. This is the auto-fixable companion to ESLint's built-in func-style rule.

Why use it: The built-in func-style: ["error", "expression"] rule reports function declarations but does not auto-fix them. This rule provides the auto-fix. Both rules should be used together for the best experience.

> Important: This rule depends on func-style: ["error", "expression"] being configured. If func-style is set to "declaration" or is disabled, do not enable this rule — it would conflict.

`typescript
// ✅ Good — arrow function expression
export const getToken = (): string | null => getCookie(tokenKey);

export const clearAuth = (): void => {
removeToken();
clearStorage();
};

const isAuthenticated = (): boolean => {
const token = getToken();
return !!token;
};

// ❌ Bad — function declaration
export function getToken(): string | null {
return getCookie(tokenKey);
}

export function clearAuth(): void {
removeToken();
clearStorage();
}

function isAuthenticated(): boolean {
const token = getToken();
return !!token;
}
`

---

$3

What it does: Enforces naming conventions for functions:
- camelCase required
- 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, and consistent Handler suffix makes event handlers easy to identify.

`javascript
// ✅ 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 (auto-fixed) — missing Handler suffix
function getUserData() {} // → getUserDataHandler
function setUserName() {} // → setUserNameHandler
function fetchUsers() {} // → fetchUsersHandler

// ❌ Bad (auto-fixed) — PascalCase to camelCase
function GetUserData() {} // → getUserDataHandler
function FetchStatus() {} // → fetchStatusHandler
`

---

$3

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,
}) => (


// ❌ 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
};
`

---

$3

What it does: When function parameters span multiple lines, ensures each parameter is on its own line with consistent indentation.

Why use it: Mixed formatting (some params on same line, some on different lines) is confusing. One per line is scannable and easy to edit.

`javascript
// ✅ Good — each param on own line
function createUser(
name,
email,
password,
role,
) {}

const handler = (
event,
context,
callback,
) => {};

// ✅ Good — short params can stay on one line
function add(a, b) {}

// ❌ Bad — mixed formatting
function createUser(name,
email, password,
role) {}

// ❌ Bad — some on same line, some not
const handler = (event, context,
callback) => {};
`

---

$3

What it does: Removes empty lines within function parameter lists — between parameters and after opening/before closing parentheses.

Why use it: Empty lines in parameter lists waste space and make parameters harder to scan as a group.

`javascript
// ✅ Good — no empty lines
function createUser(
name,
email,
role,
) {}

const handler = (
event,
context,
) => {};

// ❌ Bad — empty line between params
function createUser(
name,

email,

role,
) {}

// ❌ Bad — empty line after opening paren
const handler = (

event,
context,
) => {};
`

🪝 Hook Rules

$3

What it does: Enforces consistent multi-line formatting for React hooks that take a callback and dependency array (useEffect, useCallback, useMemo, useLayoutEffect).

Why use it: Hooks with callbacks and dependencies are complex. Multi-line formatting makes the callback, return cleanup, and dependencies clearly visible.

`javascript
// ✅ Good — callback and deps clearly separated
useEffect(
() => {
fetchData();
},
[userId],
);

useCallback(
() => {
handleSubmit(data);
},
[data, handleSubmit],
);

useMemo(
() => expensiveCalculation(items),
[items],
);

// ✅ Good — cleanup function visible
useEffect(
() => {
const subscription = subscribe();

return () => subscription.unsubscribe();
},
[subscribe],
);

// ❌ Bad — everything crammed on one line
useEffect(() => { fetchData(); }, [userId]);

// ❌ Bad — hard to see dependencies
useCallback(() => { handleSubmit(data); }, [data, handleSubmit]);
`

---

$3

What it does: When a hook's dependency array exceeds the threshold (default: 2), each dependency goes on its own line.

Why use it: Long dependency arrays are hard to scan and diff. One per line makes it easy to see what changed and catch missing/extra dependencies.

`javascript
// ✅ Good — 2 or fewer deps stay inline
useEffect(() => {}, [userId]);
useEffect(() => {}, [userId, token]);

// ✅ Good — 3+ deps get one per line
useEffect(
() => {},
[
userId,
token,
refreshToken,
],
);

useCallback(
() => handleSubmit(data),
[
data,
handleSubmit,
validateForm,
showError,
],
);

// ❌ Bad — too many deps on one line
useEffect(() => {}, [userId, token, refreshToken, apiUrl]);

// ❌ Bad — deps should be one per line when expanded
useEffect(() => {}, [
userId, token, refreshToken,
]);
`

Options:

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| maxDeps | integer | 2 | Maximum dependencies to keep on single line |

`javascript
// Example: Allow up to 3 dependencies on single line
"code-style/hook-deps-per-line": ["error", { maxDeps: 3 }]
`

$3

What it does: Enforces boolean useState variables to start with valid prefixes (is, has, with, without).

Why use it: Consistent boolean state naming makes code more predictable and self-documenting. When you see isLoading, you immediately know it's a boolean state.

`typescript
// ✅ Good — boolean state with proper prefix
const [isLoading, setIsLoading] = useState(false);
const [hasError, setHasError] = useState(false);
const [isAuthenticated, setIsAuthenticated] = useState(true);
const [withBorder, setWithBorder] = useState(false);

// ❌ Bad — boolean state without prefix
const [loading, setLoading] = useState(false);
const [authenticated, setAuthenticated] = useState(true);
const [error, setError] = useState(false);
`

Customization Options:

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| booleanPrefixes | string[] | ["is", "has", "with", "without"] | Replace default prefixes entirely |
| extendBooleanPrefixes | string[] | [] | Add additional prefixes to defaults |
| allowPastVerbBoolean | boolean | false | Allow past verb names without prefix (disabled, selected) |
| allowContinuousVerbBoolean | boolean | false | Allow continuous verb names without prefix (loading, saving) |

`javascript
// Example: Allow "loading" and "disabled" without prefix
"code-style/use-state-naming-convention": ["error", {
allowPastVerbBoolean: true,
allowContinuousVerbBoolean: true
}]

// Example: Add "should" prefix
"code-style/use-state-naming-convention": ["error", {
extendBooleanPrefixes: ["should"]
}]
`

📥 Import/Export Rules

$3

What it does: Enforces importing from folder index files using absolute paths (aliases like @/) instead of relative paths or deep file imports. Files within the same module folder must use relative imports (./ or ../) instead of absolute paths to avoid circular dependencies through the index file. Auto-fixes absolute imports to own module folder into relative paths. 🔧

Why use it:
- Absolute imports are cleaner than ../../../components
- Index imports create a public API for each folder
- Refactoring file locations doesn't break imports
- Encourages proper module organization
- Relative imports within the same module folder avoid circular dependencies

`javascript
// ✅ Good — import from index files using alias
import { Button, Input } from "@/components";
import { useAuth, useUser } from "@/hooks";
import { fetchUsers } from "@/apis";
import { formatDate } from "@/utils";

// ✅ Good — assets allow deep imports by default
import logo from "@/assets/images/logo.png";

// ✅ Good — relative import within the same module folder (siblings)
// File: utils/formatters.js
import { isNumber } from "./validators";

// ✅ Good — relative import within the same module folder (nested)
// File: data/auth/forget-password/index.ts
import { guestLoginData } from "../../login/guest";

// ❌ Bad — absolute import to own module folder (should use relative)
// File: data/auth/forget-password/index.ts
import { guestLoginData } from "@/data";
// → use relative import instead: import { guestLoginData } from "../../login/guest";

// ❌ Bad — relative imports across different folders
import { Button } from "../../components";
import { useAuth } from "../../../hooks";

// ❌ Bad — deep imports into component internals
import { Button } from "@/components/buttons/primary-button";
import { useAuth } from "@/hooks/auth/useAuth";
import { fetchUsers } from "@/apis/users/fetchUsers";
`

Default Allowed Folders:
actions, apis, assets, atoms, components, config, configs, constants, contexts, data, enums, helpers, hooks, interfaces, layouts, lib, middlewares, pages, providers, reducers, redux, requests, routes, schemas, services, store, styles, theme, thunks, types, ui, utils, utilities, views

Customization Options:

| Option | Type | Description |
|--------|------|-------------|
| extraAllowedFolders | string[] | Add custom folders that can be imported with @/folder. Extends defaults without replacing them. Use when your project has folders like features/, modules/, etc. |
| extraReduxSubfolders | string[] | Add Redux-related subfolders that can be imported directly (@/selectors) or nested (@/redux/selectors). Default subfolders: actions, reducers, store, thunks, types |
| extraDeepImportFolders | string[] | Add folders where direct file imports are allowed (@/assets/images/logo.svg). Use for folders without index files like images, fonts, etc. Default: assets |
| aliasPrefix | string | Change the path alias prefix if your project uses something other than @/ (e.g., ~/, src/) |
| allowedFolders | string[] | Completely replace the default allowed folders list. Use only if you need full control over which folders are valid |
| reduxSubfolders | string[] | Completely replace the default Redux subfolders list |
| deepImportFolders | string[] | Completely replace the default deep import folders list |

`javascript
// Example: Add custom folders to the defaults
"code-style/absolute-imports-only": ["error", {
extraAllowedFolders: ["features", "modules"],
extraDeepImportFolders: ["images", "fonts"]
}]
`

---

$3

What it does: Formats export statements consistently:
- export { always on the same line as export keyword
- ≤3 specifiers stay on one line (collapsed)
- 4+ specifiers get one per line (expanded)
- Proper spacing and trailing commas

Why use it: Consistent export formatting improves readability. Short exports stay compact, long exports become scannable.

`javascript
// ✅ Good — 3 or fewer specifiers stay compact
export { Button };
export { Button, Input };
export { Button, Input, Select };

// ✅ Good — 4+ specifiers expand with one per line
export {
Button,
Input,
Select,
Checkbox,
};

// ✅ Good — re-exports follow same rules
export { Button, Input, Select } from "./components";
export {
createUser,
updateUser,
deleteUser,
getUser,
} from "./api";

// ❌ Bad — no spaces
export {Button,Input,Select};

// ❌ Bad — keyword on different line
export
{ Button };

// ❌ Bad — too many on one line
export { Button, Input, Select, Checkbox, Radio };
`

Options:

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| maxSpecifiers | integer | 3 | Maximum specifiers to keep on single line |

`javascript
"code-style/export-format": ["error", { maxSpecifiers: 4 }]
`

---

$3

What it does: Formats import statements consistently:
- import { on the same line as import keyword
- } from on the same line as closing brace
- ≤3 specifiers stay on one line (collapsed)
- 4+ specifiers get one per line (expanded)

Why use it: Consistent import formatting improves readability and makes diffs cleaner when adding/removing imports.

`javascript
// ✅ Good — 3 or fewer specifiers stay compact
import { useState } from "react";
import { Button, Input } from "@/components";
import { get, post, put } from "@/api";

// ✅ Good — 4+ specifiers expand with one per line
import {
useState,
useEffect,
useCallback,
useMemo,
} from "react";

import {
Button,
Input,
Select,
Checkbox,
} from "@/components";

// ❌ Bad — no spaces
import {useState,useEffect} from "react";

// ❌ Bad — keyword on different line
import
{ Button } from "@/components";

// ❌ Bad — from on different line
import { Button }
from "@/components";

// ❌ Bad — too many on one line
import { useState, useEffect, useCallback, useMemo, useRef } from "react";
`

Options:

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| maxSpecifiers | integer | 3 | Maximum specifiers to keep on single line |

`javascript
"code-style/import-format": ["error", { maxSpecifiers: 4 }]
`

---

$3

What it does: Removes any leading or trailing whitespace inside import path strings.

Why use it: Spaces in module paths are almost always typos and can cause import resolution issues.

`javascript
// ✅ Good — no extra spaces
import { Button } from "@mui/material";
import React from "react";
import styles from "./styles.css";

// ❌ Bad — leading space
import { Button } from " @mui/material";

// ❌ Bad — trailing space
import React from "react ";

// ❌ Bad — both
import styles from " ./styles.css ";
`

---

$3

What it does: Enforces different export formatting rules for index files vs regular files:
- Index files: No blank lines between exports, use shorthand or import-export style
- Regular files: Require blank lines between exports

Why use it: Index files are re-export aggregators and should be compact. Regular files benefit from spacing between exports for readability.

Regular files (non-index):
`javascript
// ✅ Good — blank lines between exports
export const API_URL = "/api";

export const MAX_RETRIES = 3;

export const fetchData = async () => {};

// ❌ Bad — no blank lines in regular file
export const API_URL = "/api";
export const MAX_RETRIES = 3;
export const fetchData = async () => {};
`

Index files — Style: "shorthand" (default):
`javascript
// ✅ Good — shorthand re-exports, no blank lines
export { Button } from "./button";
export { Input, Select } from "./form";
export { Modal } from "./modal";
export { useAuth, useUser } from "./hooks";
`

Index files — Style: "import-export":
`javascript
// ✅ Good — imports grouped, single export at bottom
import { Button } from "./button";
import { Input, Select } from "./form";
import { Modal } from "./modal";

export {
Button,
Input,
Modal,
Select,
};
`

Options:

| Option | Type | Default | Description |
|--------|------|---------|-------------|
| style | "shorthand" \| "import-export" | "shorthand" | Export style for index files |

`javascript
"code-style/index-export-style": ["error", { style: "import-export" }]
`

---

$3

What it does: Index files (index.ts, index.tsx, index.js, index.jsx`) should only contain imports and re-exports, not any code definitions. All definitions (types, interfaces, functions, variables, classes) should be moved to