How Umi 4 Solves ESLint Pain Points with a Stable, Transparent, and Fast Linting Setup

ESLint is widely used to enforce code quality, and many rules can automatically fix issues. In Umi 3 the lint command bundled ESLint, Prettier, and Stylelint, but developers often faced four main problems: excessive rule count, unstable dependencies, opaque configuration, and poor performance.

Umi 4 addresses these issues with a comprehensive linting solution. First, rule overload is reduced by clearly separating responsibilities: Prettier handles style rules while ESLint focuses only on quality‑related rules, resulting in just over 60 enabled rules.

Second, dependency instability—caused by ESLint’s design where Config and Plugin are resolved from the project root and npm’s hoisting behavior—is mitigated. In the short term, Umi 4 applies @rushstack/eslint-patch/modern-module-resolution to adjust plugin resolution to start from the Config’s directory. Long‑term plans include pre‑bundling Config and Plugin dependencies.

Third, the configuration is no longer a black box. Umi 4 stops inheriting external configs and directly lists the required plugins and rules, ensuring that upstream changes do not affect users and allowing the framework itself to update safely.

Fourth, performance problems linked to TypeScript type‑aware linting are eliminated. Umi 3 enabled type‑aware rules based on the proportion of TypeScript files, which required a full project type check on each lint run, slowing CI from 19 seconds to 1‑3 seconds. Umi 4 disables these type‑aware rules, treating them as style concerns handled by Prettier.

References:

Umi 4 ESLint rule list: https://github.com/umijs/umi-next/blob/ad0dc988b0c2b98be5f71ae44a6f357612ede2f1/packages/lint/src/config/eslint/rules/recommended.ts#L5

@rushstack/eslint-patch: https://github.com/microsoft/rushstack/tree/master/eslint/eslint-patch

Linting with Type Information: https://typescript-eslint.io/docs/linting/type-linting/