eslint vs js-beautify vs prettier vs standard

JavaScript 代码质量与格式化工具架构对比

eslint、prettier、js-beautify 和 standard 都是前端工程中用于维护代码一致性的核心工具，但它们解决的问题层面不同。eslint 是一个可插拔的 Linting 工具，主要用于发现代码中的逻辑错误和潜在问题，同时也支持风格检查；prettier 是一个固执的代码格式化程序，专注于通过解析 AST 来统一代码风格，不关心逻辑错误；standard 是基于 ESLint 封装的零配置风格指南，强制推行一套特定的规范；js-beautify 是一个较老的格式化工具，支持 JS、HTML 和 CSS 的美化，但在现代前端工作流中逐渐被 Prettier 取代。

npm下载趋势

3 年

GitHub Stars 排名

统计详情

npm包名称	下载量	Stars	大小	Issues	发布时间	License
npm包名称	下载量	Stars	大小	Issues	发布时间	License
eslint	0	27,311	2.91 MB	111	12 天前	MIT
js-beautify	0	8,973	982 kB	463	1 年前	MIT
prettier	0	51,965	8.6 MB	1,405	1 天前	MIT
standard	0	29,430	164 kB	128	2 年前	MIT

ESLint vs Prettier vs Standard vs js-beautify: 代码质量与格式化深度对比

在前端工程化体系中，eslint、prettier、js-beautify 和 standard 都扮演着代码规范守门员的角色，但它们的底层原理和适用场景有明显区别。理解这些差异能帮助架构师为团队选择最合适的工具组合。让我们从核心定位、配置方式、修复能力和工作流集成四个方面进行深度对比。

🎯 核心定位：代码质量 vs 代码风格

eslint 的核心是 Linting（代码检查）。

它通过静态分析查找代码中的逻辑错误和潜在 Bug。
它也检查风格，但主要目的是保证代码质量。

// eslint: 检查逻辑错误
// 配置示例 .eslintrc.js
module.exports = {
  rules: {
    'no-unused-vars': 'error', // 报错：未使用的变量
    'eqeqeq': 'warn'           // 警告：使用 == 而不是 ===
  }
};

prettier 的核心是 Formatting（格式化）。

它不关心代码逻辑是否正确，只关心代码长得是否一致。
它通过解析代码生成 AST，然后按统一规则重新打印。

// prettier: 统一风格
// 配置示例 .prettierrc
{
  "semi": true,               // 强制使用分号
  "singleQuote": true,        // 强制使用单引号
  "printWidth": 80            // 每行最大字符数
}

standard 的核心是零配置规范。

它基于 ESLint，但预设了一套不可更改的规则。
它的目标是消除配置文件的维护成本。

// standard: 零配置规范
// 通常在 package.json 中声明
{
  "name": "my-project",
  "standard": {
    "globals": [ "jQuery" ]   // 仅允许少量覆盖
  }
}

js-beautify 的核心是文本美化。

它更像是一个文本处理工具，基于规则缩进和换行。
它对代码语义的理解不如 Prettier 深。

// js-beautify: 基础美化
// 配置示例 .jsbeautifyrc
{
  "indent_size": 2,           // 缩进大小
  "brace_style": "collapse",  // 大括号风格
  "preserve-newlines": true   // 保留空行
}

🛠️ 配置方式：灵活定制 vs 约定优于配置

配置管理的复杂度直接影响团队的维护成本。

eslint 提供极高的灵活性。

你可以继承社区配置（如 eslint:recommended）。
也可以编写自定义插件。

# eslint: 初始化配置
npx eslint --init
# 生成 .eslintrc.js 或 eslint.config.js

prettier 配置简单且有限。

它故意限制了可配置项，避免团队陷入风格争论。
大多数项目甚至不需要配置文件。

# prettier: 检查配置
npx prettier --check .
# 如果有 .prettierrc 则读取，否则使用默认值

standard 几乎不需要配置。

它的口号是“无配置”。
如果需要修改，只能通过特定方式覆盖。

# standard: 运行检查
npx standard
# 自动读取 package.json 中的 standard 字段，无需单独文件

js-beautify 配置较为传统。

支持命令行参数和配置文件。
适合对格式化细节有古老习惯的项目。

# js-beautify: 命令行指定配置
npx js-beautify -f file.js --indent-size 4
# 或读取 .jsbeautifyrc

🔄 自动修复：智能重写 vs 文本替换

自动修复能力能显著提升开发效率，但不同工具的实现深度不同。

eslint 可以修复部分问题。

它能修复风格问题，也能修复部分逻辑问题（如添加缺失的分号）。
使用 --fix 标志。

// eslint: 自动修复
// 原始代码
var x = 1
if(x==2){ console.log('hi') }

// 运行: eslint --fix file.js
// 修复后 (取决于规则)
var x = 1;
if (x == 2) { console.log('hi'); }

prettier 专注于格式化修复。

它会完全重写代码格式，保证 100% 一致。
使用 --write 标志。

// prettier: 自动格式化
// 原始代码
const x=1

// 运行: prettier --write file.js
// 修复后
const x = 1;

standard 继承 ESLint 的修复能力。

它使用 ESLint 的修复引擎。
使用 --fix 标志。

// standard: 自动修复
// 运行: standard --fix
// 行为与 eslint --fix 类似，但规则集固定

js-beautify 进行文本级修复。

它主要处理缩进和空格。
使用 -r (replace) 标志。

// js-beautify: 自动美化
// 运行: js-beautify -r file.js
// 修复后：仅调整缩进和换行，不改变语法结构

🚀 工作流集成：CLI 与编辑器插件

在实际开发中，工具需要融入编辑器和 CI 流程。

eslint 拥有最丰富的生态。

支持所有主流编辑器（VS Code, WebStorm）。
支持 eslint-loader 或 eslint-webpack-plugin。

// package.json: 集成脚本
{
  "scripts": {
    "lint": "eslint src/**",
    "lint:fix": "eslint src/** --fix"
  }
}

prettier 通常作为保存时触发。

编辑器插件在保存文件时自动运行。
也支持 CLI 用于 CI 检查。

// package.json: 集成脚本
{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

standard 简化了集成步骤。

因为无配置，CI 脚本非常简单。
编辑器插件直接启用即可。

// package.json: 集成脚本
{
  "scripts": {
    "test": "standard",
    "fix": "standard --fix"
  }
}

js-beautify 集成相对基础。

主要通过 CLI 或编辑器插件调用。
较少用于现代化的 Git Hooks 流程。

// package.json: 集成脚本
{
  "scripts": {
    "beautify": "js-beautify -r src/**/*.js"
  }
}

📊 总结对比表

特性	`eslint`	`prettier`	`standard`	`js-beautify`
主要用途	代码质量 + 风格	代码风格	代码风格 (零配置)	代码美化
配置难度	高 (灵活)	低 (固执)	极低 (无配置)	中 (传统)
逻辑检查	✅ 支持	❌ 不支持	✅ 支持 (基于 ESLint)	❌ 不支持
修复能力	部分修复	完全格式化	部分修复	文本美化
现代推荐度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐

💡 架构师建议

eslint + prettier 是现代前端的标准组合。

让 eslint 负责捕捉 Bug 和逻辑问题。
让 prettier 负责所有风格相关的格式化。
这种分工最清晰，维护成本最低。

standard 适合特定场景。

如果团队不想花时间讨论或维护 ESLint 配置，且能接受 StandardJS 的风格，它是一个高效的启动方案。
但要注意，它的规则可能过于严格，难以适应所有项目。

js-beautify 建议仅在遗留项目中使用。

在新项目中，Prettier 的 AST 解析能力能更好地处理现代 JavaScript 语法（如可选链、空值合并）。
js-beautify 更适合处理非 JS 文件（如 HTML/CSS）的简单美化，如果 Prettier 不支持的话。

最终结论：对于大多数专业前端团队，首选 eslint 配合 prettier。这种组合提供了最强大的质量控制能力和最一致的代码风格，同时保持了配置的灵活性。

如何选择: eslint vs js-beautify vs prettier vs standard

eslint:
选择 eslint 如果你需要深度定制代码规则，或者需要检查除了风格之外的逻辑错误（如未使用的变量、潜在的空指针）。它是大型项目和质量要求严格团队的首选，通常与 Prettier 配合使用。
js-beautify:
选择 js-beautify 如果你正在维护旧项目，或者需要格式化 Prettier 不支持的特定文件类型（如某些模板语言）。在新项目中，通常建议优先考虑 Prettier。
prettier:
选择 prettier 如果团队希望消除关于代码风格的争论，并且想要一个“开箱即用”的格式化体验。它最适合与 ESLint 搭配，由 Prettier 负责风格，ESLint 负责质量。
standard:
选择 standard 如果团队希望零配置启动，并且愿意接受社区约定的标准风格，不想花费时间维护 ESLint 配置文件。它适合小型团队或快速原型开发。

与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。

与js-beautify类似的npm包

js-beautify 是一个用于格式化和美化 JavaScript、HTML 和 CSS 代码的工具。它可以帮助开发者将代码转换为更易读的格式，提升代码的可维护性。使用 js-beautify，开发者可以自定义缩进、换行和其他格式化选项，从而满足特定的代码风格需求。这个工具特别适合需要处理大量代码或希望保持代码一致性的项目。

一个主要的替代品是 prettier。Prettier 是一个流行的代码格式化工具，支持多种编程语言，包括 JavaScript、TypeScript、HTML 和 CSS。与 js-beautify 不同，Prettier 采用了一种更为严格的格式化方式，旨在消除代码风格上的争议。Prettier 自动格式化代码，使其符合预设的风格规则，确保团队成员之间的代码一致性。它的无配置选项使得新用户可以快速上手，而不需要花费时间去调整格式化规则。

对于那些需要更灵活格式化选项的开发者，js-beautify 提供了更多的自定义功能，而对于希望快速实现一致代码风格的团队，Prettier 则是一个理想的选择。

查看比较: 比较 js-beautify 和 prettier。

与prettier类似的npm包

prettier 是一个流行的代码格式化工具，旨在确保代码的一致性和可读性。它支持多种语言和框架，能够自动格式化代码，使其符合预定义的风格。使用 Prettier，开发者可以专注于编写代码，而不必担心代码风格问题，从而提高开发效率。尽管 Prettier 是一个强大的工具，但在代码格式化和风格检查方面还有其他一些替代方案。以下是几个替代品：

eslint 是一个广泛使用的 JavaScript 代码检查工具，主要用于识别和报告代码中的问题。虽然 ESLint 主要关注代码质量和潜在错误，但它也可以通过配置规则来格式化代码。与 Prettier 不同，ESLint 更加注重代码的质量和一致性，而不是仅仅格式化代码。因此，许多开发者选择将 ESLint 和 Prettier 一起使用，以获得最佳的代码质量和格式化效果。
js-beautify 是一个用于格式化 JavaScript、HTML 和 CSS 代码的工具。它提供了多种配置选项，可以根据开发者的需求自定义代码格式。尽管 js-beautify 功能强大，但与 Prettier 相比，它的使用和配置可能稍显复杂。js-beautify 更适合那些需要对代码格式进行细致控制的开发者。
standard 是一种无配置的 JavaScript 代码风格指南，旨在提供一致的代码风格。它内置了一组规则，开发者无需进行额外的配置即可使用。Standard 适合那些希望快速上手并保持代码风格一致的项目。虽然它的灵活性不如 Prettier，但它提供了一种简单的方式来确保代码的一致性。

要查看 Prettier 与 ESLint、js-beautify 和 Standard 的比较，请访问：比较 eslint vs js-beautify vs prettier vs standard。

与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。

eslint

js-beautify

prettier

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.