如何在VSCode中格式化TypeScript代码？配置TSLint和Prettier的指南

星夢妙者

发布时间：2025-09-03 11:53:01

912人浏览过

来源于php中文网

原创

使用Prettier和ESLint在VSCode中格式化TypeScript代码，需安装Prettier与ESLint扩展，通过npm安装prettier、eslint、@typescript-eslint/parser、@typescript-eslint/eslint-plugin、eslint-config-prettier和eslint-plugin-prettier依赖，创建.prettierrc.json配置格式化规则，.eslintrc.js集成ESLint与Prettier并启用TypeScript支持，配置.vscode/settings.json实现保存时自动格式化与修复，可选添加npm脚本和husky+lint-staged在提交时校验，确保代码风格统一与质量合规。

如何在vscode中格式化typescript代码？配置tslint和prettier的指南

要在VSCode中高效地格式化TypeScript代码，核心策略是结合使用Prettier作为代码风格格式化工具，以及ESLint（而非已弃用的TSLint）作为代码质量和规范检查工具。通过在VSCode中安装相应的扩展并进行项目级别的配置，你可以实现代码的自动格式化和错误提示，确保团队代码风格的一致性与代码质量。

解决方案

配置一个现代的TypeScript项目格式化工作流，通常涉及以下几个步骤：

安装VSCode扩展：
- ```
Prettier - Code formatter
```
  ：这是我们主要的格式化工具。
- ```
ESLint
```
  ：用于代码风格检查和潜在错误提示。
项目初始化与依赖安装： 在你的项目根目录，通过npm或yarn安装必要的开发依赖。我通常会这么做：
```
npm install --save-dev prettier eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-config-prettier eslint-plugin-prettier
# 或者用 yarn
# yarn add --dev prettier eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-config-prettier eslint-plugin-prettier
```
这里面，
```
prettier
```
是格式化核心，
```
ESLint
```
是检查核心。
```
@typescript-eslint/parser
```
让ESLint能理解TypeScript语法，
```
@typescript-eslint/eslint-plugin
```
提供TypeScript特有的ESLint规则。
```
eslint-config-prettier
```
负责关闭ESLint中与Prettier冲突的格式化规则，避免两者“打架”。
```
eslint-plugin-prettier
```
则把Prettier的格式化问题作为ESLint的错误报告出来，这样ESLint就能统一处理所有代码规范问题。
创建Prettier配置文件 (
```
.prettierrc.json
```
)：在项目根目录创建此文件，定义你的格式化偏好。例如：
```
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 100
}
```
这些设置决定了分号、单引号、缩进宽度、尾随逗号和行宽等格式细节。

创建ESLint配置文件 (

.eslintrc.js

)：在项目根目录创建此文件。这是一个典型的配置示例：

module.exports = {
  parser: '@typescript-eslint/parser', // 指定ESLint解析器为TypeScript
  extends: [
    'eslint:recommended', // ESLint推荐的基础规则
    'plugin:@typescript-eslint/recommended', // TypeScript推荐规则
    'plugin:prettier/recommended' // 将Prettier规则作为ESLint规则，并禁用冲突规则
  ],
  parserOptions: {
    ecmaVersion: 2020, // 允许解析最新的ES特性
    sourceType: 'module', // 允许使用import/export
    project: './tsconfig.json' // 如果需要更高级的TypeScript规则，指定tsconfig
  },
  rules: {
    // 在这里可以覆盖或添加自定义的ESLint规则
    // 例如：'no-console': 'warn',
    // 'prettier/prettier': ['error', { "endOfLine": "auto" }] // 强制Prettier规则
  }
};

这个配置告诉ESLint如何解析TypeScript代码，继承了推荐的TypeScript规则集，并且最关键的是，它集成了Prettier，让ESLint来处理所有格式化问题。

配置VSCode工作区设置 (

.vscode/settings.json

)：在项目根目录创建

.vscode

文件夹，并在其中创建

settings.json

文件。这是让VSCode自动应用这些规则的关键：

{
  "editor.defaultFormatter": "esbenp.prettier-vscode", // 指定Prettier为默认格式化工具
  "editor.formatOnSave": true, // 保存时自动格式化
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true // 保存时自动修复ESLint报告的问题
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

这些设置确保当你保存TypeScript文件时，Prettier会自动格式化它，同时ESLint也会尝试修复它能自动解决的代码质量问题。

添加npm脚本（可选但推荐）： 在

package.json

中添加格式化和检查脚本，方便团队成员统一执行：

"scripts": {
  "lint": "eslint \"{src,apps,libs}/**/*.ts\"",
  "lint:fix": "eslint \"{src,apps,libs}/**/*.ts\" --fix",
  "format": "prettier --write \"{src,apps,libs}/**/*.ts\""
}

这样，运行

npm run format

就能对整个项目进行Prettier格式化，

npm run lint

检查ESLint问题，

npm run lint:fix

则尝试自动修复。

为什么Tslint已经过时了，我们现在应该用什么？

说实话，Tslint在TypeScript社区里曾经是个好伙伴，但技术迭代就是这样无情。它在2019年左右就宣布停止维护了，并且官方推荐迁移到ESLint。这背后有很多原因，但最主要的是ESLint生态系统的成熟度和社区的活跃度。

ESLint本身就是JavaScript代码检查的行业标准，拥有庞大的插件库和规则集，几乎你能想到的任何代码风格或潜在问题，ESLint都有对应的解决方案。当TypeScript越来越流行时，ESLint社区也迅速响应，通过

@typescript-eslint/parser

和

@typescript-eslint/eslint-plugin

提供了对TypeScript的完美支持。这意味着你可以在一个工具中同时检查JavaScript和TypeScript代码，这对于混合项目来说简直是福音。

现在，我们几乎都转向ESLint了。它不仅能检查语法错误和潜在的运行时问题，还能强制执行各种代码风格规则。相较于Tslint，ESLint的性能也往往更好，配置起来也更灵活。所以，如果你的项目还在用Tslint，我真心建议你花点时间迁移过来，你会发现一个更广阔、更活跃的生态。

Prettier和ESLint：它们各自扮演什么角色，以及如何协同工作？

理解Prettier和ESLint的角色，就像理解一支乐队里的主唱和伴奏。它们各司其职，却又密不可分。

Prettier 就像乐队的“风格总监”，它只关心代码的“好看程度”。它的核心理念是“有主见的格式化”，这意味着它会接管所有关于代码风格的决策：缩进、换行、空格、分号、引号等等。你几乎不需要自己去争论这些细节，Prettier会按照一套预设的、经过深思熟虑的规则来统一你的代码风格。它的好处是极大地减少了代码审查时关于风格的争论，让开发者可以专注于代码的逻辑本身。它不关心你的代码有没有bug，只关心它是不是整洁、一致。

ESLint 则是乐队的“质量控制经理”，它更关心代码的“健康状况”。ESLint会检查潜在的错误（比如未使用的变量、无法访问的代码）、强制执行最佳实践（比如禁止使用

eval

）、以及确保代码符合团队定义的复杂规则（比如函数圈复杂度不能过高）。它能帮助你发现那些可能导致bug或降低代码可维护性的问题。ESLint也有一部分格式化规则，但这正是它与Prettier需要协调的地方。

通义千问

阿里巴巴推出的全能AI助手

下载

它们如何协同工作？

关键在于避免“内讧”。ESLint自身也有一些格式化相关的规则，比如“一行最多多少个字符”、“是否需要分号”等。如果这些规则与Prettier的规则冲突，就会出现一个工具帮你改了，另一个又给你改回去的尴尬局面。

解决这个问题的方案是：

eslint-config-prettier
：这个插件的作用就是“劝架”。它会禁用所有ESLint中与Prettier冲突的格式化规则。这样一来，ESLint就不再插手代码风格，把这个任务完全交给Prettier。
eslint-plugin-prettier
：这个插件则更进一步，它把Prettier作为ESLint的一个规则来运行。这意味着，如果Prettier发现你的代码没有按照它的规则格式化，
```
eslint-plugin-prettier
```
就会把这个格式化问题报告成一个ESLint错误。这样，你就可以通过ESLint的统一报告来看到所有代码质量和格式化的问题，并且可以利用ESLint的自动修复功能 (
```
--fix
```
) 来一并解决。

所以，最终的工作流是：Prettier负责格式化，ESLint负责检查代码质量，并通过

eslint-config-prettier

和

eslint-plugin-prettier

确保两者和谐共处，共同维护代码的整洁与健康。

如何定制化你的格式化规则，以适应团队或个人偏好？

定制化规则是让这些工具真正为我所用的重要一步。毕竟，每个团队、每个项目，甚至每个开发者，都有自己的一些“小癖好”。

Prettier的定制化： Prettier的定制相对简单直接，因为它本身就是“有主见”的，可配置项不多，但核心的几个足以满足大多数需求。你只需要修改项目根目录下的

.prettierrc.json

文件。

一些我常用或推荐的配置项：

```
semi
```
:
```
true
```
(在语句末尾添加分号) 或
```
false
```
(不添加)。我个人偏向
```
true
```
，习惯使然。
```
singleQuote
```
:
```
true
```
(使用单引号) 或
```
false
```
(使用双引号)。我通常设为
```
true
```
，感觉更简洁。
```
tabWidth
```
: 2 (缩进2个空格) 或 4 (缩进4个空格)。这是个永恒的争论，团队统一就好，我个人喜欢2。
```
trailingComma
```
:
```
"all"
```
(在所有可能的地方添加尾随逗号，包括函数参数) 或
```
"es5"
```
(只在ES5有效的地方添加) 或
```
"none"
```
(不添加)。
```
"all"
```
对于Git diff和多行列表比较友好。
```
printWidth
```
: 100 (每行最大字符数)。超过这个长度Prettier会尝试换行。根据显示器大小和个人习惯调整。
```
arrowParens
```
:
```
"always"
```
(箭头函数参数总是带括号) 或
```
"avoid"
```
(单个参数时省略括号)。我通常设为
```
"always"
```
，保持一致性。

你可以通过查阅Prettier的官方文档来获取所有可配置项的详细说明。

ESLint的定制化： ESLint的定制则更为强大和灵活，因为它允许你覆盖、添加或禁用几乎任何规则。这都在你的

.eslintrc.js

文件中完成。

覆盖继承的规则： 在

rules

字段下，你可以重新定义从

extends

继承而来的规则。例如，如果你觉得

plugin:@typescript-eslint/recommended

里的

no-explicit-any

规则太严格，可以这样覆盖它：

rules: {
  '@typescript-eslint/no-explicit-any': 'off', // 关闭对any类型的检查
  // 或者设置为警告而不是错误
  // '@typescript-eslint/no-explicit-any': 'warn',
  'no-console': ['warn', { allow: ['warn', 'error'] }] // 允许console.warn和console.error，但禁止console.log
}

规则通常有三个级别：

"off"

(关闭)、

"warn"

(警告，不阻止提交)、

"error"

(错误，会阻止提交)。

添加自定义规则： 你可以根据团队的具体需求添加ESLint没有内置的规则，通常这需要自定义ESLint插件，但对于大多数情况，直接使用现有插件提供的规则就足够了。

针对特定文件或目录的规则： ESLint允许你使用

overrides

字段来为不同的文件模式应用不同的规则。这在一些特殊场景下非常有用，比如测试文件：

overrides: [
  {
    files: ['**/*.test.ts', '**/*.spec.ts'], // 匹配测试文件
    rules: {
      'no-undef': 'off', // 测试文件中可能存在全局变量，暂时关闭
      '@typescript-eslint/explicit-function-return-type': 'off' // 测试函数可能不需要明确返回类型
    }
  }
]

团队强制执行： 配置好这些规则后，最重要的是如何在团队中强制执行。除了VSCode的自动保存格式化，你还可以结合 Git Hooks。

Husky 和 lint-staged：
```
husky
```
允许你在Git事件（如
```
pre-commit
```
）发生时运行脚本。
```
lint-staged
```
则可以让你只对Git暂存区中的文件运行linter和formatter，而不是整个项目，这能大大提高效率。

安装依赖：
```
npm install --save-dev husky lint-staged
```
在
```
package.json
```
中配置：
```
"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*.{ts,tsx}": [
    "eslint --fix",
    "prettier --write",
    "git add"
  ]
}
```
这样，每次你
```
git commit
```
时，
```
husky
```
会触发
```
lint-staged
```
，它会检查并格式化你即将提交的
```
.ts
```
或
```
.tsx
```
文件。如果有ESLint错误无法自动修复，提交就会被阻止，确保只有符合规范的代码才能进入仓库。这招非常有效，能从源头上保证代码质量。