eslint-plugin-nextfriday 1.2.3 → 1.4.0

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # eslint-plugin-nextfriday
 
+## 1.4.0
+
+### Minor Changes
+
+- [#26](https://github.com/next-friday/eslint-plugin-nextfriday/pull/26) [`e90935a`](https://github.com/next-friday/eslint-plugin-nextfriday/commit/e90935a56129ff84efc9df5de3f43e8e4a61af16) Thanks [@nextfridaydeveloper](https://github.com/nextfridaydeveloper)! - Add two new rules to improve code readability and debugging: `no-complex-inline-return` disallows complex inline expressions (such as ternary operators, logical expressions, or `new` expressions) directly in return statements, requiring extraction to a `const` variable instead; and `no-logic-in-params` prohibits using logic or conditions (e.g., ternary, logical, comparison, or negation operators) within function parameters, enforcing the use of intermediate `const` variables to enhance clarity and allow inspection of values.
+
+## 1.3.0
+
+### Minor Changes
+
+- [#24](https://github.com/next-friday/eslint-plugin-nextfriday/pull/24) [`59d1932`](https://github.com/next-friday/eslint-plugin-nextfriday/commit/59d193258d6ffd19d6fd90515626d826732e30b3) Thanks [@nextfridaydeveloper](https://github.com/nextfridaydeveloper)! - Add new prefer-named-param-types rule that enforces using named interfaces or type aliases instead of inline object type literals for function
+
 ## 1.2.3
 
 ### Patch Changes

package/README.md

@@ -65,7 +65,10 @@ export default [
       "nextfriday/prefer-destructuring-params": "error",
       "nextfriday/no-explicit-return-type": "error",
       "nextfriday/prefer-import-type": "error",
+      "nextfriday/prefer-named-param-types": "error",
       "nextfriday/prefer-react-import-types": "error",
+      "nextfriday/no-complex-inline-return": "error",
+      "nextfriday/no-logic-in-params": "error",
       "nextfriday/jsx-pascal-case": "error",
       "nextfriday/prefer-interface-over-inline-types": "error",
       "nextfriday/react-props-destructure": "error",
@@ -106,19 +109,22 @@ module.exports = {
 
 ## Rules
 
-| Rule                                                                                   | Description                                                      | Fixable |
-| -------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------- |
-| [no-emoji](docs/rules/NO_EMOJI.md)                                                     | Disallow emojis in code                                          | ❌      |
-| [file-kebab-case](docs/rules/FILE_KEBAB_CASE.md)                                       | Enforce kebab-case filenames for .ts and .js files               | ❌      |
-| [jsx-pascal-case](docs/rules/JSX_PASCAL_CASE.md)                                       | Enforce PascalCase filenames for .jsx and .tsx files             | ❌      |
-| [md-filename-case-restriction](docs/rules/MD_FILENAME_CASE_RESTRICTION.md)             | Enforce SNAKE_CASE filenames for .md files                       | ❌      |
-| [prefer-destructuring-params](docs/rules/PREFER_DESTRUCTURING_PARAMS.md)               | Enforce destructuring for functions with multiple parameters     | ❌      |
-| [no-explicit-return-type](docs/rules/NO_EXPLICIT_RETURN_TYPE.md)                       | Disallow explicit return types on functions                      | ✅      |
-| [prefer-import-type](docs/rules/PREFER_IMPORT_TYPE.md)                                 | Enforce using 'import type' for type-only imports                | ✅      |
-| [prefer-interface-over-inline-types](docs/rules/PREFER_INTERFACE_OVER_INLINE_TYPES.md) | Enforce interface declarations over inline types for React props | ❌      |
-| [prefer-react-import-types](docs/rules/PREFER_REACT_IMPORT_TYPES.md)                   | Enforce direct imports from 'react' instead of React.X           | ✅      |
-| [react-props-destructure](docs/rules/REACT_PROPS_DESTRUCTURE.md)                       | Enforce destructuring props inside React component body          | ❌      |
-| [enforce-readonly-component-props](docs/rules/ENFORCE_READONLY_COMPONENT_PROPS.md)     | Enforce Readonly wrapper for React component props               | ✅      |
+| Rule                                                                                   | Description                                                                   | Fixable |
+| -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------- |
+| [no-emoji](docs/rules/NO_EMOJI.md)                                                     | Disallow emojis in code                                                       | ❌      |
+| [file-kebab-case](docs/rules/FILE_KEBAB_CASE.md)                                       | Enforce kebab-case filenames for .ts and .js files                            | ❌      |
+| [jsx-pascal-case](docs/rules/JSX_PASCAL_CASE.md)                                       | Enforce PascalCase filenames for .jsx and .tsx files                          | ❌      |
+| [md-filename-case-restriction](docs/rules/MD_FILENAME_CASE_RESTRICTION.md)             | Enforce SNAKE_CASE filenames for .md files                                    | ❌      |
+| [prefer-destructuring-params](docs/rules/PREFER_DESTRUCTURING_PARAMS.md)               | Enforce destructuring for functions with multiple parameters                  | ❌      |
+| [no-explicit-return-type](docs/rules/NO_EXPLICIT_RETURN_TYPE.md)                       | Disallow explicit return types on functions                                   | ✅      |
+| [prefer-import-type](docs/rules/PREFER_IMPORT_TYPE.md)                                 | Enforce using 'import type' for type-only imports                             | ✅      |
+| [prefer-named-param-types](docs/rules/PREFER_NAMED_PARAM_TYPES.md)                     | Enforce named types for function parameters with object types                 | ❌      |
+| [prefer-interface-over-inline-types](docs/rules/PREFER_INTERFACE_OVER_INLINE_TYPES.md) | Enforce interface declarations over inline types for React props              | ❌      |
+| [prefer-react-import-types](docs/rules/PREFER_REACT_IMPORT_TYPES.md)                   | Enforce direct imports from 'react' instead of React.X                        | ✅      |
+| [react-props-destructure](docs/rules/REACT_PROPS_DESTRUCTURE.md)                       | Enforce destructuring props inside React component body                       | ❌      |
+| [enforce-readonly-component-props](docs/rules/ENFORCE_READONLY_COMPONENT_PROPS.md)     | Enforce Readonly wrapper for React component props                            | ✅      |
+| [no-complex-inline-return](docs/rules/NO_COMPLEX_INLINE_RETURN.md)                     | Disallow complex inline expressions in return statements - prefer const first | ❌      |
+| [no-logic-in-params](docs/rules/NO_LOGIC_IN_PARAMS.md)                                 | Disallow logic or conditions in function parameters - extract to const first  | ❌      |
 
 ## Configurations
 
@@ -134,7 +140,10 @@ Basic configuration without JSX-specific rules:
 - `nextfriday/prefer-destructuring-params`: `"error"`
 - `nextfriday/no-explicit-return-type`: `"error"`
 - `nextfriday/prefer-import-type`: `"error"`
+- `nextfriday/prefer-named-param-types`: `"error"`
 - `nextfriday/prefer-react-import-types`: `"error"`
+- `nextfriday/no-complex-inline-return`: `"error"`
+- `nextfriday/no-logic-in-params`: `"error"`
 
 #### `base/recommended`
 

package/docs/rules/NO_COMPLEX_INLINE_RETURN.md

@@ -0,0 +1,136 @@
+# no-complex-inline-return
+
+Disallow complex inline expressions in return statements - prefer extracting to a const first.
+
+## Rule Details
+
+This rule enforces a pattern where complex expressions (ternary operators, logical expressions, new expressions) are extracted to a const variable before being returned. This improves code readability and makes debugging easier by allowing you to inspect intermediate values.
+
+**Incorrect** code for this rule:
+
+```typescript
+function waitForLoad(targetWindow: Window) {
+  return targetWindow.document.readyState === "complete"
+    ? Promise.resolve()
+    : new Promise<void>((resolve) => {
+        targetWindow.addEventListener(
+          "load",
+          () => {
+            resolve();
+          },
+          {
+            once: true,
+          },
+        );
+      });
+}
+
+function getValue(condition: boolean) {
+  return condition ? "yes" : "no";
+}
+
+function getUser(user: User | null) {
+  return user || defaultUser;
+}
+
+function createInstance() {
+  return new MyClass();
+}
+
+function checkStatus(a: boolean, b: boolean) {
+  return a && b;
+}
+```
+
+**Correct** code for this rule:
+
+```typescript
+function waitForLoad(targetWindow: Window) {
+  const loadPromise =
+    targetWindow.document.readyState === "complete"
+      ? Promise.resolve()
+      : new Promise<void>((resolve) => {
+          targetWindow.addEventListener(
+            "load",
+            () => {
+              resolve();
+            },
+            {
+              once: true,
+            },
+          );
+        });
+
+  return loadPromise;
+}
+
+function getValue(condition: boolean) {
+  const value = condition ? "yes" : "no";
+  return value;
+}
+
+function getUser(user: User | null) {
+  const activeUser = user || defaultUser;
+  return activeUser;
+}
+
+function createInstance() {
+  const instance = new MyClass();
+  return instance;
+}
+
+function checkStatus(a: boolean, b: boolean) {
+  const isValid = a && b;
+  return isValid;
+}
+
+// Simple returns are still allowed
+function getName() {
+  return "John Doe";
+}
+
+function getAge() {
+  return 42;
+}
+
+function callFunction() {
+  return someFunction();
+}
+
+function getMath() {
+  return a + b;
+}
+```
+
+## Benefits
+
+- **Better readability**: Complex logic is separated from the return statement
+- **Easier debugging**: Intermediate values can be inspected in debuggers
+- **Self-documenting**: Variable names can describe what the complex expression represents
+- **Consistent style**: Enforces a uniform approach to handling complex return values
+
+## When Not To Use
+
+- For very simple projects where inline expressions are preferred
+- When you prefer a more compact coding style
+- In cases where the expression is trivial and doesn't benefit from extraction
+
+## What This Rule Checks
+
+This rule flags the following patterns when used directly in return statements:
+
+- **Ternary expressions** (conditional operators): `condition ? value1 : value2`
+- **Logical expressions**: `a && b`, `a || b`, `a ?? b`
+- **New expressions**: `new MyClass()`
+
+The following are allowed in return statements:
+
+- Simple values (literals, variables)
+- Function calls
+- Binary expressions (math operations like `a + b`)
+- Object/array literals
+- Member expressions (`obj.prop`)
+
+## Related Rules
+
+- No related rules

package/docs/rules/NO_LOGIC_IN_PARAMS.md

@@ -0,0 +1,122 @@
+# no-logic-in-params
+
+Disallow logic or conditions in function parameters - extract to a const variable first.
+
+## Rule Details
+
+This rule enforces a pattern where complex expressions (logical operators, ternary operators, comparison operators) are extracted to a const variable before being passed as function arguments. This improves code readability, makes debugging easier, and helps maintain cleaner function calls.
+
+**Incorrect** code for this rule:
+
+```typescript
+// Nullish coalescing
+functionFoo(bar ?? baz);
+
+// Ternary operator
+handleUser(isActive ? activeUser : inactiveUser);
+
+// Logical AND
+processData(hasPermission && isValid);
+
+// Logical OR
+setConfig(customConfig || defaultConfig);
+
+// Comparison operators
+validateInput(value > 100);
+checkEquality(a === b);
+
+// Negation
+toggleFeature(!isEnabled);
+
+// Multiple parameters with logic
+createUser(username, age >= 18, status === "active");
+
+// New expression with logic
+new MyClass(a || b);
+```
+
+**Correct** code for this rule:
+
+```typescript
+// Extract logic to a variable first
+const value = bar ?? baz;
+functionFoo(value);
+
+const user = isActive ? activeUser : inactiveUser;
+handleUser(user);
+
+const canProcess = hasPermission && isValid;
+processData(canProcess);
+
+const config = customConfig || defaultConfig;
+setConfig(config);
+
+const isValid = value > 100;
+validateInput(isValid);
+
+const areEqual = a === b;
+checkEquality(areEqual);
+
+const shouldDisable = !isEnabled;
+toggleFeature(shouldDisable);
+
+const isAdult = age >= 18;
+const isActive = status === "active";
+createUser(username, isAdult, isActive);
+
+const param = a || b;
+new MyClass(param);
+
+// Simple values are still allowed
+functionFoo(bar);
+functionFoo(42);
+functionFoo("string");
+functionFoo(obj.property);
+functionFoo(getValue());
+
+// Arithmetic operations are allowed
+calculate(a + b);
+multiply(x * y);
+
+// Object/array literals are allowed
+configure({ key: "value" });
+process([1, 2, 3]);
+```
+
+## Benefits
+
+- **Better readability**: Logic is separated from function calls, making code easier to scan
+- **Easier debugging**: Intermediate values can be inspected in debuggers before being passed to functions
+- **Self-documenting**: Variable names describe what the complex expression represents
+- **Consistent style**: Enforces a uniform approach to handling complex function arguments
+- **Reduced cognitive load**: Readers don't need to mentally evaluate expressions while also understanding function calls
+
+## When Not To Use
+
+- For very simple projects where inline expressions are preferred
+- When you prefer a more compact coding style
+- In cases where the expression is trivial and doesn't benefit from extraction
+
+## What This Rule Checks
+
+This rule flags the following patterns when used as function arguments:
+
+- **Ternary expressions** (conditional operators): `condition ? value1 : value2`
+- **Logical expressions**: `a && b`, `a || b`, `a ?? b`
+- **Comparison operators**: `===`, `!==`, `==`, `!=`, `>`, `<`, `>=`, `<=`
+- **Type checking operators**: `in`, `instanceof`
+- **Negation operator**: `!value`
+
+The following are allowed as function arguments:
+
+- Simple values (literals, variables)
+- Function calls
+- Member expressions (`obj.prop`)
+- Arithmetic operations (`a + b`, `a * b`, etc.)
+- Object/array literals
+- Template literals
+- Spread operators (`...args`)
+
+## Related Rules
+
+- [no-complex-inline-return](./NO_COMPLEX_INLINE_RETURN.md) - Similar rule but for return statements

package/docs/rules/PREFER_NAMED_PARAM_TYPES.md

@@ -0,0 +1,172 @@
+# prefer-named-param-types
+
+Enforce named interfaces or types instead of inline object types for function parameters.
+
+## Rule Details
+
+This rule enforces extracting inline object type annotations for function parameters into named interfaces or type aliases. This promotes better code organization, reusability, and readability across your codebase.
+
+Examples of **incorrect** code for this rule:
+
+```typescript
+// Destructured parameter with inline type
+const foo = ({ bar, baz }: { bar: string; baz: number }) => {
+  console.log(bar, baz);
+};
+
+// Regular parameter with inline type
+const foo = (params: { bar: string; baz: number }) => {
+  const { bar, baz } = params;
+  console.log(bar, baz);
+};
+
+// Function declaration
+function createUser(data: { name: string; email: string; role: "admin" | "user" }) {
+  return { ...data, createdAt: Date.now() };
+}
+
+// Function expression
+const handler = function (data: { id: number; name: string }) {
+  return data.id;
+};
+
+// Multiple parameters with inline types
+const foo = (first: { a: string; b: number }, second: { x: boolean; y: string }) => {
+  return { first, second };
+};
+```
+
+Examples of **correct** code for this rule:
+
+```typescript
+// Using interface
+interface Params {
+  bar: string;
+  baz: number;
+}
+
+const foo = (params: Params) => {
+  const { bar, baz } = params;
+  console.log(bar, baz);
+};
+
+// Using type alias
+type UserData = {
+  name: string;
+  email: string;
+  role: "admin" | "user";
+};
+
+const createUser = (data: UserData) => {
+  return { ...data, createdAt: Date.now() };
+};
+
+// Primitive types are allowed
+const foo = (value: string) => {
+  return value;
+};
+
+const bar = (count: number, enabled: boolean) => {
+  return count > 0 && enabled;
+};
+
+// Functions with no parameters
+const baz = () => {
+  return "no params";
+};
+
+// Named types with destructuring
+interface Config {
+  theme: string;
+  locale: string;
+}
+
+const setup = (config: Config) => {
+  const { theme, locale } = config;
+  console.log(theme, locale);
+};
+```
+
+## Why?
+
+### Benefits of named parameter types:
+
+1. **Reusability**: Named types can be reused across multiple functions
+2. **Better organization**: Separates type definitions from function logic
+3. **Improved readability**: Makes function signatures cleaner and easier to understand
+4. **Better IDE support**: Enhanced autocomplete, refactoring, and navigation
+5. **Documentation**: Named types serve as clear documentation of function APIs
+6. **Extensibility**: Types and interfaces can be extended and composed more easily
+7. **Type inference**: Named types can improve TypeScript's type inference in complex scenarios
+
+## Rule Scope
+
+This rule applies to:
+
+- All function types: arrow functions, function expressions, and function declarations
+- Function parameters with inline object type literals
+- Method definitions with inline object type parameters
+- TypeScript method signatures
+
+The rule triggers when:
+
+- A parameter has an inline object type literal (e.g., `{ bar: string; baz: number }`)
+- The parameter is destructured with an inline type (e.g., `({ bar, baz }: { bar: string; baz: number })`)
+
+The rule allows:
+
+- Primitive type annotations (string, number, boolean, etc.)
+- Named types and interfaces
+- Type aliases
+- Functions with no parameters
+- Array types (e.g., `string[]`)
+- Union/intersection types without object literals
+
+## When Not To Use It
+
+This rule should not be used if you:
+
+- Prefer inline types for simple, one-off function parameters
+- Are working with very simple functions that don't benefit from type extraction
+- Have specific code style requirements that favor inline types
+- Are maintaining legacy code with established patterns
+
+## Configuration
+
+This rule is included in the following configurations:
+
+- `nextfriday/base`
+- `nextfriday/base/recommended`
+- `nextfriday/react`
+- `nextfriday/react/recommended`
+- `nextfriday/nextjs`
+- `nextfriday/nextjs/recommended`
+
+To enable this rule manually:
+
+```json
+{
+  "rules": {
+    "nextfriday/prefer-named-param-types": "error"
+  }
+}
+```
+
+## Relationship to Other Rules
+
+This rule complements but differs from `prefer-interface-over-inline-types`:
+
+- `prefer-interface-over-inline-types`: Focuses on React component props with complexity criteria
+- `prefer-named-param-types`: Applies to ALL functions with inline object types, regardless of complexity
+
+Both rules can be used together for comprehensive type organization.
+
+## Compatibility
+
+- TypeScript 3.0+ (interface and type alias declarations)
+- ESLint 9+ with flat config
+- Works with all function types in JavaScript/TypeScript
+
+## Version
+
+This rule was introduced in eslint-plugin-nextfriday v1.2.3.