eslint vs semistandard vs standard vs xo

JavaScript 代码风格与静态检查工具选型指南

eslint、semistandard、standard 和 xo 都是用于 JavaScript 项目的代码质量保障工具，它们通过静态分析帮助开发者发现潜在错误、强制统一代码风格并提升可维护性。eslint 是一个高度可配置的插件化 lint 工具，而 semistandard、standard 和 xo 则是在 eslint 基础上封装的“零配置”或“低配置”方案，各自预设了不同的代码风格规则集。这些工具的核心目标一致，但在灵活性、默认规则、配置方式和扩展能力上存在显著差异，适合不同团队协作模式和技术偏好。

npm下载趋势

3 年

GitHub Stars 排名

统计详情

npm包名称	下载量	Stars	大小	Issues	发布时间	License
npm包名称	下载量	Stars	大小	Issues	发布时间	License
eslint	0	27,249	2.91 MB	115	11 天前	MIT
semistandard	0	1,415	47.6 kB	0	3 年前	MIT
standard	0	29,435	164 kB	129	2 年前	MIT
xo	0	7,970	114 kB	9	2 个月前	MIT

JavaScript 代码风格与静态检查工具深度对比：eslint vs semistandard vs standard vs xo

在现代前端工程中，代码一致性不仅是风格问题，更是可维护性和协作效率的关键。eslint、semistandard、standard 和 xo 都基于 ESLint 引擎，但设计理念迥异 —— 从完全自由到高度约束。本文从真实开发场景出发，深入剖析它们的技术差异。

⚙️ 配置哲学：自由定制 vs 约定优于配置

eslint 提供完全开放的配置模型，所有规则均可开关或调整。

通过 .eslintrc.js、.eslintrc.json 或 package.json 中的 eslintConfig 字段定义规则。
支持插件（如 eslint-plugin-react）和可共享配置（如 airbnb）。

// .eslintrc.js 示例
module.exports = {
  extends: ['eslint:recommended', 'plugin:react/recommended'],
  rules: {
    'no-console': 'warn',
    'react/prop-types': 'off'
  },
  parserOptions: { ecmaVersion: 2022 }
};

standard 主张“无配置”，所有规则固化在包内。

安装即用，无需任何配置文件。
规则不可覆盖（除非 fork 项目），强制团队遵守同一套标准。

# 安装后直接运行
npx standard

semistandard 是 standard 的变体，仅修改一条核心规则：允许分号。

其他规则（如缩进、引号）与 standard 完全一致。
同样不支持自定义规则。

# 使用方式与 standard 几乎相同
npx semistandard

xo 在“零配置”基础上提供有限扩展点。

默认启用严格规则，但可通过 xo 字段在 package.json 中微调。
内置 TypeScript、React、Prettier 支持，无需额外插件。

// package.json
{
  "xo": {
    "semicolon": false,
    "rules": {
      "no-await-in-loop": "off"
    }
  }
}

📏 默认规则差异：分号、引号与变量声明

分号处理

eslint: 默认不限制，需显式配置 semi 规则。
standard: 禁止分号（semi: ["error", "never"]）。
semistandard: 要求分号（semi: ["error", "always"]）。
xo: 默认禁止分号，但可通过 semicolon: true 开启。

// standard / xo (默认)
const a = 1

// semistandard / eslint (配置后)
const a = 1;

引号风格

eslint: 默认不限制，常用 quotes: ["error", "single"]。
standard/semistandard: 强制单引号。
xo: 默认单引号，可通过 quoteProps 调整。

// 所有工具默认行为
const msg = 'Hello'

// 双引号会报错（除字符串内容包含单引号外）

变量声明

eslint: 默认不限制 var，但 eslint:recommended 不包含此规则。
standard/semistandard: 禁止 var，强制 const/let。
xo: 默认禁止 var（no-var: "error"），且要求 const 优先于 let。

// 所有工具（除基础 eslint）均报错
var name = 'John'

// 正确写法
const name = 'John'

🔌 扩展能力：插件与框架支持

eslint 拥有最丰富的生态系统。

官方支持 TypeScript（通过 @typescript-eslint/parser）。
社区提供 Vue、Svelte、MDX 等解析器和插件。

// eslint + TypeScript 配置
module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  extends: ['plugin:@typescript-eslint/recommended']
};

standard/semistandard 仅支持原生 JavaScript。

无法直接处理 TypeScript 或 JSX（需额外工具链转换）。
无插件机制，功能封闭。

xo 开箱支持现代语法。

内置 TypeScript 解析（需安装 typescript 依赖）。
自动识别 React 项目并启用相关规则。

# xo 直接 lint .ts 文件
npx xo src/index.ts

🛠️ 与格式化工具集成

eslint 本身不处理代码格式化，但可通过 eslint --fix 修复部分问题。

常与 Prettier 配合使用，需配置 eslint-config-prettier 关闭冲突规则。

// .eslintrc.js + Prettier
extends: [
  'eslint:recommended',
  'prettier' // 关闭 ESLint 中与 Prettier 冲突的规则
]

standard/semistandard 内置简单格式化能力（standard --fix）。

仅修复可安全自动修正的问题（如未使用变量）。
不处理缩进、换行等复杂格式。

xo 深度集成 Prettier。

运行 xo --fix 时自动调用 Prettier 格式化代码。
无需单独配置 Prettier 规则，遵循 XO 内置约定。

# xo 自动格式化
npx xo --fix

🧪 实际项目中的典型工作流

场景 1：大型企业级应用（多团队协作）

需求：统一跨团队规范，支持 TypeScript、React，允许局部覆盖规则。
推荐：eslint + @typescript-eslint + eslint-plugin-react
原因：只有 eslint 能提供细粒度控制，例如在 utils 目录禁用 React 规则。

场景 2：开源工具库（快速启动）

需求：最小化配置，立即获得社区认可的代码风格。
推荐：standard 或 semistandard
原因：安装即用，降低贡献者门槛；选择取决于团队是否接受无分号风格。

场景 3：现代前端项目（Vite + React + TS）

需求：开箱即用的严格检查，自动格式化，支持最新语法。
推荐：xo
原因：内置对 TS/JSX/Prettier 的支持，避免繁琐配置，同时比 standard 更严格。

⚠️ 注意事项与陷阱

standard/semistandard 的局限性：无法处理非 JS 文件（如 .vue），在复杂项目中可能成为瓶颈。
xo 的隐式依赖：使用 TypeScript 时需手动安装 typescript 包，否则解析失败。
eslint 的学习曲线：新手易陷入配置地狱，建议从 eslint:recommended 逐步扩展。

📊 总结对比表

特性	`eslint`	`semistandard`	`standard`	`xo`
配置自由度	完全自由	无	无	有限（package.json 微调）
分号要求	可配置	必须	禁止	默认禁止（可开启）
TypeScript 支持	需插件	不支持	不支持	内置
Prettier 集成	需手动配置	无	无	开箱即用
适用场景	大型/复杂项目	喜欢分号的简洁项目	极简主义项目	现代前端项目

💡 最终建议

如果你的项目需要长期演进或涉及多技术栈，eslint 是唯一可持续的选择。
如果你追求极简启动且团队接受其风格约束，standard 或 semistandard 能省去大量配置时间。
如果你在构建现代 Web 应用（含 TS/React），xo 在零配置和严格性之间取得了最佳平衡。

记住：工具只是手段，核心目标是减少团队在代码风格上的争论，把精力聚焦在业务逻辑上。

如何选择: eslint vs semistandard vs standard vs xo

eslint:
选择 eslint 如果你需要完全控制 lint 规则、支持多种框架（如 React、Vue、TypeScript）或需要与现有项目规范深度集成。它适合大型团队或对代码风格有严格定制需求的场景，但需要投入时间配置规则和维护 .eslintrc 文件。
semistandard:
选择 semistandard 如果你希望采用 StandardJS 的核心规则，但允许使用分号（;）结尾。它适合那些喜欢 StandardJS 简洁哲学，又不愿放弃分号以避免 ASI（自动分号插入）潜在问题的团队，提供比 standard 更宽松的语法约束。
standard:
选择 standard 如果你追求极致简洁、无需配置的开发体验，并接受其无分号、单引号、2 空格缩进等约定。它适合小型项目、开源库或快速原型开发，能立即统一团队代码风格，但牺牲了自定义规则的自由度。
xo:
选择 xo 如果你希望在零配置基础上获得现代 JavaScript 支持（如 ES2022+、TypeScript）、更严格的默认规则（如禁止 var、强制 const/let）以及开箱即用的 Prettier 集成。它适合追求前沿实践、重视代码健壮性的现代前端项目。

与eslint类似的npm包

eslint 是一个广泛使用的 JavaScript 代码质量和风格检查工具。它帮助开发者在编写代码时遵循一致的风格和最佳实践，从而提高代码的可维护性和可读性。虽然 eslint 是一个强大的工具，但在前端开发中还有其他一些替代方案。以下是一些替代工具：

prettier 是一个代码格式化工具，旨在自动格式化代码以保持一致的风格。与 eslint 主要关注代码质量和潜在错误不同，prettier 侧重于代码的格式化。它可以与 eslint 一起使用，以确保代码既符合风格要求，又没有语法错误。对于希望提高开发效率并减少代码审查中的格式问题的团队来说，prettier 是一个理想的选择。
stylelint 是一个强大的 CSS 代码质量检查工具，专门用于检查 CSS 和预处理器语言（如 SCSS 和 LESS）的样式问题。stylelint 允许开发者定义和遵循样式指南，从而确保样式代码的一致性和可维护性。如果你的项目中有大量的 CSS 代码，使用 stylelint 可以帮助你保持样式的高质量和一致性。
tslint 是一个 TypeScript 代码质量检查工具，专门用于 TypeScript 项目。虽然 eslint 也支持 TypeScript，但 tslint 提供了一些特定于 TypeScript 的规则和功能。如果你正在开发一个 TypeScript 项目，并希望利用 TypeScript 的类型系统来提高代码质量，tslint 可能是一个合适的选择。不过需要注意的是，tslint 已经被弃用，建议使用 eslint 的 TypeScript 插件。

要查看 eslint 与 prettier、stylelint 和 tslint 的比较，请访问：比较 eslint、prettier、stylelint 和 tslint。

与semistandard类似的npm包

semistandard 是一个基于 JavaScript 的代码风格检查工具，它结合了 Standard JavaScript Style 和一些自定义的规则。这个工具旨在提供一种简单的方式来保持代码的一致性和可读性，同时避免过于严格的规则。使用 semistandard，开发者可以专注于编写高质量的代码，而不必担心代码风格问题。

尽管 semistandard 提供了良好的代码风格检查功能，但在 JavaScript 生态系统中还有其他一些替代工具可供选择。以下是一些常见的替代品：

eslint 是一个广泛使用的 JavaScript 代码检查工具，提供了高度可配置的规则集。与 semistandard 不同，eslint 允许开发者根据项目需求自定义规则，提供了更大的灵活性。它支持插件和扩展，能够处理多种 JavaScript 变体，包括 TypeScript 和 JSX。如果你需要一个功能强大且灵活的代码检查工具，eslint 是一个理想的选择。
standard 是一个无配置的 JavaScript 代码风格工具，旨在消除配置的复杂性。它提供了一套固定的规则，确保代码的一致性。与 semistandard 类似，standard 也强调简洁性和可读性，但它的规则更为严格。如果你希望采用一种简单且一致的代码风格，standard 是一个不错的选择。
xo 是一个现代的 JavaScript 代码风格检查工具，基于 eslint 构建，但提供了更为简化的配置和更好的默认规则。xo 还支持 TypeScript，并且内置了对异步代码的支持。它的目标是提供一个开箱即用的解决方案，适合希望快速上手的开发者。

要查看 semistandard 与其他工具的比较，请访问：比较 eslint vs semistandard vs standard vs xo。

与standard类似的npm包

standard 是一个 JavaScript 代码风格检查工具，旨在提供一致的代码风格和最佳实践。它不需要配置文件，遵循一套明确的规则，帮助开发者保持代码的整洁和可读性。虽然 standard 提供了一个简单的解决方案，但在 JavaScript 生态系统中，还有其他一些替代工具可以实现类似的功能。以下是一些替代品：

eslint 是一个功能强大的可配置的 JavaScript 代码检查工具，允许开发者根据项目需求自定义规则。与 standard 不同，eslint 提供了更多的灵活性和扩展性，适合需要特定规则和复杂配置的项目。如果你希望能够根据团队的需求自定义代码风格，eslint 是一个理想的选择。
prettier 是一个代码格式化工具，专注于自动格式化代码以保持一致性。与 standard 和 eslint 不同，prettier 主要关注代码的格式，而不是代码的质量和潜在错误。它可以与 eslint 配合使用，以确保代码既符合格式要求，又遵循最佳实践。如果你希望在团队中实现一致的代码格式，prettier 是一个很好的选择。
semistandard 是一个基于 standard 的 JavaScript 代码风格检查工具，提供了一些额外的灵活性。它允许使用一些常见的 JavaScript 特性，同时保持 standard 的大部分规则。如果你喜欢 standard 的风格，但希望有一些额外的灵活性，semistandard 是一个不错的选择。
xo 是一个现代化的 JavaScript 代码风格检查工具，内置了许多最佳实践和默认规则。它支持异步代码和 TypeScript，并且可以通过配置文件进行自定义。xo 的目标是提供一个简单而强大的工具，帮助开发者保持代码质量。如果你希望使用一个现代化且易于使用的工具，xo 是一个值得考虑的选项。

查看比较：比较 eslint vs prettier vs semistandard vs standard vs xo。

与xo类似的npm包

xo 是一个现代的 JavaScript 代码检查工具，旨在帮助开发者保持代码的一致性和质量。它基于 ESLint，提供了一系列默认配置，旨在减少配置的复杂性，并鼓励最佳实践。虽然 xo 提供了强大的代码检查功能，但在 JavaScript 生态系统中还有其他一些替代工具可供选择。以下是几个替代方案：

eslint 是一个广泛使用的代码检查工具，允许开发者定义和执行代码风格和最佳实践的规则。它具有高度的可配置性，支持自定义规则和插件，使其适用于各种项目需求。ESLint 是一个非常流行的选择，适合需要灵活性和可扩展性的开发者。
prettier 是一个代码格式化工具，专注于确保代码的一致性和可读性。与 ESLint 不同，Prettier 主要关注代码的格式，而不是代码质量或潜在的错误。它可以与 ESLint 一起使用，以确保代码既符合格式规范，又遵循最佳实践。如果你的主要目标是保持代码的格式一致性，Prettier 是一个理想的选择。
standard 是一个无配置的 JavaScript 代码风格指南，旨在简化代码检查过程。它提供了一套预定义的规则，旨在消除配置的复杂性。Standard 的目标是让开发者能够快速上手，而不必花费时间在配置上。如果你希望采用一种简单且一致的代码风格，Standard 是一个不错的选择。

要查看 xo 与 eslint、prettier 和 standard 的比较，请访问：比较 eslint vs prettier vs standard vs xo。

eslint

semistandard

standard

eslint的README

ESLint

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code. In many ways, it is similar to JSLint and JSHint with a few exceptions:

ESLint uses Espree for JavaScript parsing.
ESLint uses an AST to evaluate patterns in code.
ESLint is completely pluggable, every single rule is a plugin and you can add more at runtime.

Installation and Usage

Prerequisites

To use ESLint, you must have Node.js (^20.19.0, ^22.13.0, or >=24) installed and built with SSL support. (If you are using an official Node.js distribution, SSL is always built in.)

If you use ESLint's TypeScript type definitions, TypeScript 5.3 or later is required.

npm Installation

You can install and configure ESLint using this command:

npm init @eslint/config@latest

After that, you can run ESLint on any file or directory like this:

npx eslint yourfile.js

pnpm Installation

To use ESLint with pnpm, we recommend setting up a .npmrc file with at least the following settings:

auto-install-peers=true
node-linker=hoisted

This ensures that pnpm installs dependencies in a way that is more compatible with npm and is less likely to produce errors.

Configuration

You can configure rules in your eslint.config.js files as in this example:

import { defineConfig } from "eslint/config";

export default defineConfig([
	{
		files: ["**/*.js", "**/*.cjs", "**/*.mjs"],
		rules: {
			"prefer-const": "warn",
			"no-constant-binary-expression": "error",
		},
	},
]);

The names "prefer-const" and "no-constant-binary-expression" are the names of rules in ESLint. The first value is the error level of the rule and can be one of these values:

"off" or 0 - turn the rule off
"warn" or 1 - turn the rule on as a warning (doesn't affect exit code)
"error" or 2 - turn the rule on as an error (exit code will be 1)

The three error levels allow you fine-grained control over how ESLint applies rules (for more configuration options and details, see the configuration docs).

Version Support

The ESLint team provides ongoing support for the current version and six months of limited support for the previous version. Limited support includes critical bug fixes, security issues, and compatibility issues only.

ESLint offers commercial support for both current and previous versions through our partners, Tidelift and HeroDevs.

See Version Support for more details.

Code of Conduct

ESLint adheres to the OpenJS Foundation Code of Conduct.

Filing Issues

Before filing an issue, please be sure to read the guidelines for what you're reporting:

Frequently Asked Questions

Does ESLint support JSX?

Yes, ESLint natively supports parsing JSX syntax (this must be enabled in configuration). Please note that supporting JSX syntax is not the same as supporting React. React applies specific semantics to JSX syntax that ESLint doesn't recognize. We recommend using eslint-plugin-react if you are using React and want React semantics.

Does Prettier replace ESLint?

No, ESLint and Prettier have different jobs: ESLint is a linter (looking for problematic patterns) and Prettier is a code formatter. Using both tools is common, refer to Prettier's documentation to learn how to configure them to work well with each other.

What ECMAScript versions does ESLint support?

ESLint has full support for ECMAScript 3, 5, and every year from 2015 up until the most recent stage 4 specification (the default). You can set your desired ECMAScript syntax and other settings (like global variables) through configuration.

What about experimental features?

ESLint's parser only officially supports the latest final ECMAScript standard. We will make changes to core rules in order to avoid crashes on stage 3 ECMAScript syntax proposals (as long as they are implemented using the correct experimental ESTree syntax). We may make changes to core rules to better work with language extensions (such as JSX, Flow, and TypeScript) on a case-by-case basis.

In other cases (including if rules need to warn on more or fewer cases due to new syntax, rather than just not crashing), we recommend you use other parsers and/or rule plugins. If you are using Babel, you can use @babel/eslint-parser and @babel/eslint-plugin to use any option available in Babel.

Once a language feature has been adopted into the ECMAScript standard (stage 4 according to the TC39 process), we will accept issues and pull requests related to the new feature, subject to our contributing guidelines. Until then, please use the appropriate parser and plugin(s) for your experimental feature.

Which Node.js versions does ESLint support?

ESLint updates the supported Node.js versions with each major release of ESLint. At that time, ESLint's supported Node.js versions are updated to be:

The most recent maintenance release of Node.js
The lowest minor version of the Node.js LTS release that includes the features the ESLint team wants to use.
The Node.js Current release

ESLint is also expected to work with Node.js versions released after the Node.js Current release.

Refer to the Quick Start Guide for the officially supported Node.js versions for a given ESLint release.

Where to ask for help?

Open a discussion or stop by our Discord server.

Why doesn't ESLint lock dependency versions?

Lock files like package-lock.json are helpful for deployed applications. They ensure that dependencies are consistent between environments and across deployments.

Packages like eslint that get published to the npm registry do not include lock files. npm install eslint as a user will respect version constraints in ESLint's package.json. ESLint and its dependencies will be included in the user's lock file if one exists, but ESLint's own lock file would not be used.

We intentionally don't lock dependency versions so that we have the latest compatible dependency versions in development and CI that our users get when installing ESLint in a project.

The Twilio blog has a deeper dive to learn more.

Releases

We have scheduled releases every two weeks on Friday or Saturday. You can follow a release issue for updates about the scheduling of any particular release.

Security Policy

ESLint takes security seriously. We work hard to ensure that ESLint is safe for everyone and that security issues are addressed quickly and responsibly. Read the full security policy.

Semantic Versioning Policy

ESLint follows semantic versioning. However, due to the nature of ESLint as a code quality tool, it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, we've defined the following semantic versioning policy for ESLint:

Patch release (intended to not break your lint build)
- A bug fix in a rule that results in ESLint reporting fewer linting errors.
- A bug fix to the CLI or core (including formatters).
- Improvements to documentation.
- Non-user-facing changes such as refactoring code, adding, deleting, or modifying tests, and increasing test coverage.
- Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
Minor release (might break your lint build)
- A bug fix in a rule that results in ESLint reporting more linting errors.
- A new rule is created.
- A new option to an existing rule that does not result in ESLint reporting more linting errors by default.
- A new addition to an existing rule to support a newly-added language feature (within the last 12 months) that will result in ESLint reporting more linting errors by default.
- An existing rule is deprecated.
- A new CLI capability is created.
- New capabilities to the public API are added (new classes, new methods, new arguments to existing methods, etc.).
- A new formatter is created.
- eslint:recommended is updated and will result in strictly fewer linting errors (e.g., rule removals).
Major release (likely to break your lint build)
- eslint:recommended is updated and may result in new linting errors (e.g., rule additions, most rule option updates).
- A new option to an existing rule that results in ESLint reporting more linting errors by default.
- An existing formatter is removed.
- Part of the public API is removed or changed in an incompatible way. The public API includes:
  - Rule schemas
  - Configuration schema
  - Command-line options
  - Node.js API
  - Rule, formatter, parser, plugin APIs

According to our policy, any minor update may report more linting errors than the previous release (ex: from a bug fix). As such, we recommend using the tilde (~) in package.json e.g. "eslint": "~3.1.0" to guarantee the results of your builds.

ESM Dependencies

Since ESLint is a CommonJS package, there are restrictions on which ESM-only packages can be used as dependencies.

Packages that are controlled by the ESLint team and have no external dependencies can be safely loaded synchronously using require(esm) and therefore used in any contexts.

For external packages, we don't use require(esm) because a package could add a top-level await and thus break ESLint. We can use an external ESM-only package only in case it is needed only in asynchronous code, in which case it can be loaded using dynamic import().

These policies don't apply to packages intended for our own usage only, such as eslint-config-eslint.

License

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.