oxc-project/oxc · warning

The {name} has too many lines ({count}). Maximum allowed is

Error message

The {name} has too many lines ({count}). Maximum allowed is {max}.

What it means

Diagnostic from `max-lines-per-function`. It measures the line span of a function (including nested structures but not nested function bodies) and reports it with a human-readable name/kind produced by `get_function_name_with_kind` (e.g. "FunctionComponent `Button` has too many lines", "method `render` has too many lines"). Default `max` is 50 lines (DEFAULT_MAX_LINES_PER_FUNCTION at crates/oxc_linter/src/rules/eslint/max_lines_per_function.rs:49-54), with `skipBlankLines` and `skipComments` options.

Source

Thrown at crates/oxc_linter/src/rules/eslint/max_lines_per_function.rs:26

use schemars::JsonSchema;
use serde::Deserialize;
use serde_json::Value;

use crate::{
    AstNode,
    ast_util::{get_function_name_with_kind, iter_outer_expressions},
    context::LintContext,
    rule::{DefaultRuleConfig, Rule},
    utils::count_comment_lines,
};

fn max_lines_per_function_diagnostic(
    name: &str,
    count: u32,
    max: u32,
    span: Span,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!(
        "The {name} has too many lines ({count}). Maximum allowed is {max}."
    ))
    .with_help("Consider splitting it into smaller functions.")
    .with_label(span)
}

#[derive(Debug, Clone, JsonSchema, Deserialize)]
#[serde(rename_all = "camelCase", default, deny_unknown_fields)]
pub struct MaxLinesPerFunctionConfig {
    /// Maximum number of lines allowed in a function.
    max: u32,
    /// Skip lines containing just comments.
    skip_comments: bool,
    /// Skip lines made up purely of whitespace.
    skip_blank_lines: bool,
    /// The `IIFEs` option controls whether IIFEs are included in the line count.
    /// By default, IIFEs are not considered, but when set to `true`, they will
    /// be included in the line count for the function.

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Decompose the function: extract steps into named helpers so each unit stays under the limit (the rule's stated help suggests splitting).
  2. Enable `skipBlankLines`/`skipComments` if formatting and doc comments, not logic, are pushing functions over the line.
  3. Raise `max` for specific realities of the codebase (e.g. generated reducers) or disable the rule for test files via config overrides.

Example fix

// before
async function checkout(cart) { /* ~90 lines: validate, price, tax, discount, payment, email */ }

// after
async function checkout(cart) {
  const priced = await priceCart(cart);
  const paid = await chargePayment(priced);
  return sendReceiptEmail(paid);
}
Defensive patterns

Strategy: validation

Validate before calling

// .oxlintrc.json -> "max-lines-per-function": ["error", { "max": 50, "skipComments": true }]
// CI: oxlint fails the PR before long functions merge.

Prevention

When it happens

Trigger: A function whose own body spans more than 50 lines with defaults, e.g. a long lifecycle method, reducer switch, or setup function. Nested functions are measured separately; configuring `{ "max": 100, "skipComments": true }` shifts the threshold. The diagnostic span covers the offending function.

Common situations: React class components and big render methods; Redux reducers with many cases; test setup functions (`beforeEach` bodies) in suites; legacy jQuery-era initialization code; teams enabling the rule after the codebase already contains 100+ line functions and getting flooded.

Related errors


AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/8974fd6c4c7ab16a. Report an issue: GitHub.