📎 Feature: Extend useArrowFunction rule to cover top-level function declarations #7107

Summary

Request to extend the existing useArrowFunction rule to optionally enforce arrow functions for top-level function declarations, not just function expressions.

Problem

Currently, the useArrowFunction rule only applies to function expressions:

// ❌ Current rule flags this
const myFunc = function() { return 42; }

// ✅ But ignores this
function myFunc() { return 42; }

For teams that prefer consistent arrow function usage throughout their codebase, there's no way to enforce arrow functions for top-level function declarations.

Proposed Solution

Add a configuration option to the useArrowFunction rule to optionally include top-level function declarations:

{
  "linter": {
    "rules": {
      "complexity": {
        "useArrowFunction": {
          "level": "error",
          "options": {
            "includeTopLevelDeclarations": true
          }
        }
      }
    }
  }
}

With this configuration, the rule would flag:

// ❌ Would be flagged
function schemaFieldsToColumns(props) {
  // ...
}

// ✅ Preferred
const schemaFieldsToColumns = (props) => {
  // ...
}

ESLint Precedent

ESLint ecosystem has plugins that support similar functionality:

1. eslint-plugin-prefer-arrow

This plugin enforces arrow functions and has an option to control top-level declarations:

{
  "rules": {
    "prefer-arrow/prefer-arrow-functions": [
      "error",
      {
        "allowStandaloneDeclarations": false,  // Default: flags top-level function declarations
        "disallowPrototype": true,
        "singleReturnOnly": false,
        "classPropertiesAllowed": false
      }
    ]
  }
}

• When allowStandaloneDeclarations is false (default), the plugin flags ALL function declarations including top-level ones
• When allowStandaloneDeclarations is true, it ignores top-level function declarations but still flags nested ones

2. func-style rule combined with prefer-arrow-callback

{
  "rules": {
    "func-style": ["error", "expression", { "allowArrowFunctions": true }],
    "prefer-arrow-callback": ["error"]
  }
}

The func-style rule enforces function expressions over declarations, and when combined with allowArrowFunctions: true, it permits arrow functions as the preferred expression style.

Benefits

1. Consistency: Teams can enforce uniform arrow function usage
2. Modernization: Encourages modern ES6+ syntax patterns
3. Optional: Backward compatible - disabled by default
4. Familiar: Similar to existing ESLint plugin patterns

Considerations

• Should respect existing exceptions (generators, functions using this)
• Consider hoisting behavior differences between function declarations and arrow functions
• May be breaking for codebases relying on hoisting
• Should probably exclude function overloads (like the current rule does)

Alternative

If extending the existing rule is not preferred, a new rule like useArrowFunctionDeclarations could be introduced instead.