eslint vs prettier vs stylelint vs tslint

前端代码质量与风格自动化工具选型

eslint、prettier、stylelint 和 tslint 都是用于维护代码质量和一致性的开发工具，但它们的侧重点不同。eslint 主要用于检查 JavaScript 和 TypeScript 代码中的逻辑错误和风格问题。prettier 专注于代码格式化，确保所有代码看起来都一样。stylelint 专门用于检查 CSS 预处理器和样式表中的错误。tslint 曾经是 TypeScript 的专用检查工具，但现已废弃，官方建议迁移至 eslint。

npm下载趋势

3 年

GitHub Stars 排名

统计详情

npm包名称	下载量	Stars	大小	Issues	发布时间	License
npm包名称	下载量	Stars	大小	Issues	发布时间	License
eslint	0	27,281	2.91 MB	112	9 天前	MIT
prettier	0	51,893	8.6 MB	1,488	1 个月前	MIT
stylelint	0	11,469	954 kB	125	4 天前	MIT
tslint	0	5,906	-	1	6 年前	Apache-2.0

前端代码质量与风格自动化工具深度对比

在构建现代前端应用时，保持代码质量和风格一致至关重要。eslint、prettier、stylelint 和 tslint 是生态中最常见的四个工具，但它们解决的问题不同。理解它们的区别能帮你搭建高效的工程化体系。

🎯 核心定位：检查逻辑 vs 格式化 vs 样式检查

eslint 专注于 JavaScript 和 TypeScript 的代码质量。

它能发现逻辑错误，比如未定义的变量。
它能强制执行编码规范，比如禁止使用 var。
它通过插件系统支持几乎所有前端框架。

// eslint: .eslintrc.js 配置示例
module.exports = {
  parser: '@typescript-eslint/parser',
  rules: {
    'no-unused-vars': 'error',
    'eqeqeq': 'warn'
  }
};

prettier 专注于代码格式的统一。

它不关心代码逻辑是否正确。
它只关心缩进、换行、引号等外观问题。
它支持 JS、TS、CSS、JSON 等多种语言。

// prettier: .prettierrc 配置示例
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "printWidth": 80
}

stylelint 专注于样式表的质量。

它能检查 CSS 语法错误。
它能强制命名规范，比如 BEM 风格。
它能避免使用过时的属性。

// stylelint: .stylelintrc.json 配置示例
{
  "rules": {
    "color-no-invalid-hex": true,
    "selector-class-pattern": "^[a-z][a-zA-Z0-9]*$"
  }
}

tslint 曾经是 TypeScript 的专用检查器。

它只能检查 TypeScript 代码。
它已停止维护，功能不再更新。
它的配置方式与 eslint 类似，但已不再推荐使用。

// tslint: tslint.json 配置示例 (已废弃)
{
  "rules": {
    "no-unused-variable": true,
    "semicolon": [true, "always"]
  }
}

🛠️ 实际工作流中的协作

在现代工程实践中，这些工具通常一起使用，而不是二选一。

eslint + prettier 是标准组合。

eslint 负责保证代码不出错。
prettier 负责保证代码好看。
使用 eslint-config-prettier 关闭 eslint 中所有与格式相关的规则，避免冲突。

// eslint: 关闭与 prettier 冲突的规则
module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'prettier' // 必须放在最后，以覆盖格式规则
  ]
};

stylelint 独立运行或集成到构建流程。

它通常在 CSS 构建阶段运行。
它可以与 prettier 共存，prettier 格式化 CSS 结构，stylelint 检查 CSS 质量。

# 命令行运行示例
npx eslint src/
npx prettier --write src/
npx stylelint "src/**/*.css"

⚠️ 重要警告：TSLint 已废弃

tslint 不再适用于新项目。

官方仓库已归档，不再接受新功能。
TypeScript 团队推荐迁移到 eslint。
继续使用 tslint 会导致技术债务。

# 迁移命令示例
# 不再安装 tslint
# 改为安装 eslint 及相关插件
npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

如果你正在维护旧项目，应制定计划迁移到 eslint。typescript-eslint 项目提供了完整的规则映射，可以帮助自动化这一过程。

📊 功能对比总结

特性	`eslint`	`prettier`	`stylelint`	`tslint`
主要用途	代码质量与逻辑检查	代码格式化	样式表检查	TypeScript 检查 (已废弃)
支持语言	JS, TS, JSX, Vue 等	JS, TS, CSS, JSON 等	CSS, SCSS, Less	TypeScript 仅
配置复杂度	高 (可高度定制)	低 ( opinionated )	中 (规则丰富)	中 (已停止更新)
维护状态	✅ 活跃维护	✅ 活跃维护	✅ 活跃维护	❌ 已废弃
推荐场景	所有 JS/TS 项目	所有项目	含 CSS 的项目	无 (请迁移)

💡 最佳实践建议

对于新项目：

必选 eslint 配合 @typescript-eslint。
必选 prettier 用于格式化。
必选 stylelint 如果项目包含 CSS 模块。
忽略 tslint，不要安装。

对于旧项目：

如果正在使用 tslint，计划迁移到 eslint。
使用 tslint-to-eslint-config 工具辅助转换配置。
逐步替换规则，确保 CI 流程不被打断。

配置整合：

在 VS Code 中安装对应插件，实现保存时自动修复。
在 CI/CD 流程中加入检查步骤，阻止不符合规范的代码合并。

// package.json 脚本示例
{
  "scripts": {
    "lint": "eslint . --ext .ts,.tsx",
    "format": "prettier --write .",
    "lint:css": "stylelint \"src/**/*.css\""
  }
}

🏁 结论

这四个工具并非竞争关系，而是互补关系。eslint 和 stylelint 负责质量门禁，prettier 负责消除风格争论。tslint 已成为历史，应尽快从技术栈中移除。合理组合使用这些工具，能显著提升团队开发效率和代码可维护性 — 这是现代前端工程化的基石。

如何选择: eslint vs prettier vs stylelint vs tslint

eslint:
选择 eslint 作为 JavaScript 和 TypeScript 项目的主要代码检查工具。它拥有最丰富的插件生态，能够发现潜在的逻辑错误、未使用的变量以及复杂度过高的代码。对于新项目，建议配合 @typescript-eslint 插件使用，以获得最佳的 TypeScript 支持。
prettier:
选择 prettier 来处理所有代码的格式化工作。它 opinionated 的设计理念意味着你不需要争论缩进是 2 格还是 4 格，只需提交代码即可。它与 eslint 互补，前者管逻辑质量，后者管代码长相。
stylelint:
选择 stylelint 来管理 CSS、SCSS 或 Less 样式文件。它能防止写错属性名、强制颜色格式统一以及避免特定选择器的使用。对于大型项目或设计系统，它是保持样式一致性的必要工具。
tslint:
不要在新项目中选择 tslint。该工具已正式废弃，维护团队明确建议所有用户迁移到 eslint。继续使用 tslint 会导致无法获得最新的 TypeScript 特性支持，且未来可能面临兼容性问题。

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

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

与stylelint类似的npm包

stylelint 是一个强大的 CSS 代码质量工具，旨在帮助开发者保持样式表的一致性和可维护性。它通过 linting 机制检查 CSS 代码中的潜在问题，并提供可配置的规则集，以确保代码遵循最佳实践。虽然 stylelint 是一个优秀的选择，但在前端开发中还有其他一些替代工具可供选择。以下是几个替代方案：

eslint 是一个广泛使用的 JavaScript 代码检查工具，旨在识别和报告代码中的问题。虽然它主要用于 JavaScript，但通过插件也可以扩展到其他语言和框架。对于需要同时检查 JavaScript 和 CSS 的项目，eslint 是一个理想的选择，因为它可以帮助开发者维护代码质量并遵循一致的编码风格。
prettier 是一个代码格式化工具，旨在自动化代码的格式化过程。与 stylelint 和 eslint 不同，prettier 专注于代码的外观，而不是潜在的错误或最佳实践。它可以与其他 linting 工具结合使用，以确保代码不仅符合风格指南，还具有一致的格式。对于希望简化代码格式化过程的开发者，prettier 是一个很好的选择。
sass-lint 是一个专门针对 Sass 文件的 linting 工具。它提供了一组规则来检查 Sass 代码的质量和一致性，确保开发者遵循最佳实践。对于使用 Sass 进行样式开发的项目，sass-lint 是一个非常有用的工具，可以帮助维护代码的整洁和可读性。

查看比较：比较 eslint vs prettier vs sass-lint vs stylelint。

与tslint类似的npm包

tslint 是一个 TypeScript 代码质量工具，用于检查 TypeScript 代码中的潜在问题和不一致性。它帮助开发者遵循最佳实践，从而提高代码的可读性和可维护性。然而，随着时间的推移，tslint 已经被 ESLint 及其 TypeScript 插件所取代，因此许多开发者开始转向其他工具。以下是一些替代方案：

eslint 是一个广泛使用的 JavaScript 和 TypeScript 代码检查工具。它提供了灵活的配置选项和丰富的插件生态系统，可以帮助开发者确保代码符合特定的风格和最佳实践。ESLint 的强大之处在于它的可扩展性，允许用户根据项目需求自定义规则和功能。如果你正在寻找一个功能强大且灵活的代码检查工具，ESLint 是一个理想的选择。
prettier 是一个代码格式化工具，旨在自动化代码的格式化过程。与 ESLint 不同，Prettier 专注于代码的外观，而不是代码的质量检查。它可以与 ESLint 一起使用，以确保代码在格式和质量上都符合标准。如果你希望在团队中保持一致的代码风格，并减少因格式化引起的争议，Prettier 是一个很好的选择。
stylelint 是一个专门用于 CSS 和样式表的代码检查工具。它帮助开发者确保 CSS 代码的质量和一致性，提供了丰富的规则和插件来支持各种 CSS 预处理器和框架。如果你的项目涉及大量的 CSS 或者样式表，使用 Stylelint 可以帮助你维护高质量的样式代码。

要查看 TSLint 与 ESLint、Prettier 和 Stylelint 的比较，请访问：比较 eslint vs prettier vs stylelint vs tslint。

eslint

prettier

stylelint

tslint

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.