eslint-plugin-nextfriday 1.3.0 → 1.4.0

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # 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

package/README.md

@@ -67,6 +67,8 @@ export default [
       "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",
@@ -107,20 +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-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               | ✅      |
+| 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
 
@@ -138,6 +142,8 @@ Basic configuration without JSX-specific rules:
 - `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