开发工具精选项目

ESLint

高度可配置、可扩展的 JavaScript Linter，通过规则、插件、Parser 与 Processor 发现问题并统一代码质量规范。

GitHub 访问官网

主要语言JavaScript

开源许可MIT

项目类型开发工具

维护状态活跃维护

OVERVIEW

项目概述

ESLint 基于抽象语法树检查 ECMAScript 代码。它既提供官方推荐规则，也允许框架、TypeScript、测试工具和团队自定义插件扩展分析能力。

ESLint 是 OpenJS Foundation 旗下的 MIT 开源 JavaScript Linter。它把静态检查拆成可配置规则，并通过 Plugin、Parser、Processor、Shareable Config 和 Formatter 扩展到 TypeScript、React、Vue、测试代码、Markdown 等生态场景。现代 ESLint 默认使用 eslint.config.js / mjs 等 Flat Config：配置文件直接导出配置对象数组，可按文件 Glob 组合语言选项、插件和规则。ESLint 的重点是发现潜在错误、反模式和团队约束，并不是完整的代码格式化器或 TypeScript 编译器。

当前版本10.8.0

默认配置Flat Config

默认 ParserEspree

FEATURES

主要特点

ESLint 以规则为核心，并用可编程配置与成熟插件生态覆盖不同语言、框架和团队规范。

可组合规则系统

每条规则独立分析语法树并报告问题，可配置为 Off、Warning 或 Error，也可携带选项、自动修复和代码建议。

Flat Config

eslint.config.js、mjs、cjs 或经过额外设置的 TypeScript 配置直接导出数组，可按文件和目录组合配置对象。

庞大插件生态

插件可以提供规则、预设配置、Processor、Language 与 Parser 集成，覆盖主流框架、测试库、Imports、Node.js 和安全实践。

自定义 Parser

默认 Espree 解析标准 JavaScript；typescript-eslint、Babel 等 Parser 可让 ESLint 理解 TypeScript 或实验语法。

Processor 与多语言支持

Processor 能从 Markdown、Vue 单文件组件等文件中提取代码块再交给规则分析，新 Language API 也在扩展非 JavaScript 检查。

Shareable Config

团队或社区可以发布可复用配置，将 Plugin、规则和文件范围组合成统一基线，并在项目中继续覆盖。

自动修复与建议

`--fix` 应用规则提供的安全修复，编辑器还能展示 Suggestions，让开发者选择是否执行可能改变代码结构的调整。

TypeScript 类型化规则

配合 typescript-eslint 和 Project Service，可使用 Type Information 检查未处理 Promise、不安全赋值等仅靠语法无法识别的问题。

Config Inspector

`--inspect-config` 和 `--print-config` 可以解释某个文件最终启用了哪些配置和规则，帮助排查复杂 Flat Config。

CLI、Node API 与编辑器集成

除命令行外还提供 Node.js API、官方 VS Code 扩展和多种编辑器集成，可在保存、提交或自定义工具中运行。

缓存与增量工作流

`--cache`、`--changed` 等选项可减少重复检查，适合大型仓库、提交前 Hook 和 Pull Request 流程。

可定制报告格式

内置 Stylish、JSON、HTML 等 Formatter，也支持第三方 Formatter，便于终端阅读、CI 注释或机器处理。

USE CASES

适用场景

当项目需要在编辑器、提交检查与 CI 中持续执行可解释、可定制的代码质量规则时，ESLint 是成熟选择。

JavaScript 与 TypeScript 应用

从基础错误、未使用变量到类型感知规则，为浏览器、Node.js 和全栈代码建立持续质量门槛。

React 与其他框架项目

配合框架 Plugin 检查 Hooks、组件约定、模板代码、热更新边界和可访问性问题。

团队工程规范

将禁用 API、命名约定、Imports 规则和代码安全要求发布为 Shareable Config，供多个项目复用。

Monorepo

Flat Config 可按 Apps、Packages、测试、脚本和生成代码设置不同 Parser、Globals、Plugin 与规则。

CI 质量门禁

在 Pull Request 中阻止 Error 或 Warning 合入，并输出 JSON 等格式供代码扫描平台消费。

渐进式遗留代码治理

先使用 Warning、Overrides 或只检查变更文件，再逐步提高规则等级，避免一次性修复整个旧仓库。

自定义领域检查

团队可以编写本地或发布的 Plugin，检查内部 API、日志、权限、国际化和架构边界等专用约束。

EVALUATION

优点与注意事项

技术选型不仅要看能力，也要理解它带来的团队成本。

主要优点

ESLint 擅长的地方

JavaScript 与 TypeScript 生态成熟，资料和集成广泛
规则、Plugin、Parser、Processor 和 Formatter 扩展边界清晰
Flat Config 可直接使用 JavaScript 组合多层文件规则
typescript-eslint 能提供基于完整类型信息的深入检查
自动修复和编辑器 Suggestions 缩短问题反馈与修复周期
Shareable Config 便于在团队和多个仓库中复用规范
Config Inspector、Debug 日志和 Print Config 有助于排查复杂配置
CLI、Node API、编辑器和 CI 适配成熟，便于接入现有工作流

需要注意

采用前应考虑的问题

ESLint 不是代码 Formatter

ESLint 已弃用核心格式规则，并建议使用 Prettier、dprint 等专用 Formatter，或采用 ESLint Stylistic 社区规则。

也不能替代 TypeScript 编译器

即使启用 typescript-eslint 类型化规则，也必须继续运行 `tsc --noEmit` 或项目构建来验证完整类型正确性。

插件质量和兼容性不一

社区 Plugin 可能滞后于 ESLint、Node.js 或框架大版本，升级前应核对 Peer Dependencies、Flat Config 和维护状态。

Flat Config 迁移存在行为差异

Plugin 导入、Globals、Ignore、文件匹配和 CLI Flag 与 eslintrc 不完全相同，不能只改文件名后期待原配置等价。

配置可编程也会变复杂

配置对象顺序、Files、Ignores 和 Extends 的组合可能难以直观看懂，应为配置命名并用 Inspector 检查目标文件。

类型化 Lint 成本更高

Project Service 需要 TypeScript 构建程序并读取 TSConfig，大型 Monorepo 应优化文件范围、缓存和 CI 分工。

规则冲突需要治理

多个 Plugin 或 Shareable Config 可能启用重复、互斥或已弃用规则，团队要明确配置层级和升级负责人。

自动修复仍需审阅

大多数 Fix 很可靠，但批量升级规则或运行第三方 Plugin 修复时仍应检查 Diff、测试与生成文件范围。

Warning 策略要明确

ESLint 默认不会因 Warning 失败。CI 若要求零 Warning，应显式使用 `--max-warnings 0`，否则问题可能长期累积。

运行环境要求较新

ESLint 10.8.0 要求 Node.js ^20.19.0、^22.13.0 或 >=24，旧 CI 镜像和开发机必须先升级。

全仓扫描可能拖慢反馈

大量文件、重型 Plugin 和类型化规则会增加耗时，应排除构建产物、使用 Cache，并区分快速本地检查与完整 CI。

QUICK START

快速开始

下面从官方配置向导开始，分别配置 JavaScript、TypeScript 类型化规则、脚本、CI、配置调试和旧项目迁移。

1使用官方向导初始化

bash

npm init @eslint/config@latest

# 完成向导后检查整个项目
npx eslint .

2手动配置 JavaScript Flat Config

javascript

import js from "@eslint/js";
import { defineConfig, globalIgnores } from "eslint/config";

export default defineConfig([
  globalIgnores(["dist/**", "coverage/**"]),
  js.configs.recommended,
  {
    files: ["**/*.{js,mjs,cjs}"],
    rules: {
      "eqeqeq": "error",
      "no-console": "warn",
    },
  },
]);

3配置 TypeScript 推荐规则

javascript

import js from "@eslint/js";
import { defineConfig } from "eslint/config";
import tseslint from "typescript-eslint";

export default defineConfig({
  files: ["**/*.{js,cjs,mjs,jsx,ts,cts,mts,tsx}"],
  extends: [
    js.configs.recommended,
    tseslint.configs.recommended,
  ],
});

4启用 TypeScript 类型化检查

javascript

import { defineConfig } from "eslint/config";
import tseslint from "typescript-eslint";

export default defineConfig({
  files: ["**/*.{ts,tsx}"],
  extends: [
    tseslint.configs.recommendedTypeChecked,
  ],
  languageOptions: {
    parserOptions: {
      projectService: true,
      tsconfigRootDir: import.meta.dirname,
    },
  },
});

5添加本地修复与 CI 脚本

json

{
  "scripts": {
    "lint": "eslint . --cache",
    "lint:fix": "eslint . --cache --fix",
    "lint:ci": "eslint . --max-warnings 0",
    "typecheck": "tsc --noEmit"
  }
}

6在 GitHub Actions 中检查

yaml

name: Lint

on:
  pull_request:
  push:
    branches: [main]

jobs:
  eslint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint:ci

7检查某个文件的最终配置

bash

# 交互式查看配置来源和规则覆盖
npx eslint --inspect-config src/app.ts

# 输出该文件最终合并后的配置
npx eslint --print-config src/app.ts

8从 eslintrc 迁移到 Flat Config

bash

npx @eslint/migrate-config .eslintrc.json

# 迁移器提供起点，仍需检查插件、Ignore 和脚本
npx eslint .
npm test

下一步：先采用官方 Recommended 配置，再按真实缺陷逐步加入规则。把格式问题交给专用 Formatter，并用 `--max-warnings 0` 明确 CI 是否允许 Warning。

ALTERNATIVES

类似项目

Biome 提供一体化 Formatter 与 Linter，TypeScript 是类型化检查的常见搭档；oxlint、Stylelint 和 Prettier 则覆盖高速 Lint、样式检查与代码格式化。

TypeScript

为 JavaScript 添加类型语法，提升大型项目的开发体验。

查看项目

Biome

以 Rust 构建的 Web 工具链，在一个快速的命令行与编辑器服务中提供格式化、Lint、导入整理和代码修复。

查看项目

oxlint

Oxc 提供的高速 JavaScript 与 TypeScript Linter，兼容越来越多 ESLint 规则和插件。

访问官网

Stylelint

面向 CSS、SCSS 等样式语言的可扩展 Linter，可与 ESLint 分别治理脚本和样式。

访问官网

Prettier

专注代码格式化的工具，常与 ESLint 分工，避免把格式规则和代码质量规则混在一起。

访问官网

COMPARISON

ESLint vs Biome

ESLint 与 Biome 都能检查 JavaScript 和 TypeScript，但 ESLint 以可扩展 Linter 和成熟插件生态为核心；Biome 则用 Rust 实现的一体化工具统一 Formatter、Linter、Assist 与编辑器服务。

比较维度	ESLint	Biome
核心定位	高度可扩展的 JavaScript Linter	一体化 Web Formatter、Linter 与 Assist
实现与运行	JavaScript / Node.js	Rust 原生二进制
格式化	建议配合 Prettier、dprint 或 ESLint Stylistic	内置 Opinionated Formatter
规则生态	大量框架、测试、Imports、安全和企业 Plugin	内置规则丰富，GritQL 插件生态仍较年轻
TypeScript	typescript-eslint 支持 Parser 和类型化规则	内置解析与 Lint，但类型感知能力范围不同
非 JS 文件	依赖 Processor、Parser、Plugin 或新 Language	统一处理 JSON、CSS、GraphQL 等支持语言
配置	Flat Config 可编程、组合灵活，复杂度也更高	单一 biome.json，默认即可运行
性能取向	受 Plugin、Parser 和类型化规则影响较大	原生实现，强调快速全仓与编辑器反馈
迁移与兼容	适合延续现有 Plugin 和团队规则资产	可迁移部分 ESLint 配置，但并非所有规则都有等价实现
更适合	依赖专用插件、类型化规则和高度定制治理的团队	重视速度、较少依赖和统一工具体验的 Web 项目

如何选择

如果项目依赖 React、Vue、测试框架、Imports 或企业自定义插件，并需要 TypeScript 类型化规则，ESLint 的成熟扩展体系通常更稳妥；如果团队主要使用 Biome 稳定支持的语言，希望减少依赖并统一 Format 与 Lint，可优先评估 Biome。大型项目也可以让 Biome 负责格式化和通用规则，同时保留 ESLint 执行少量不可替代的专用规则，但应避免重复扫描与冲突诊断。

VERIFICATION