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

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

解决方案

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

1. 安装VSCode扩展：

   • Prettier - Code formatter

     ：这是我们主要的格式化工具。

   • ESLint

     ：用于代码风格检查和潜在错误提示。

2. 项目初始化与依赖安装： 在你的项目根目录，通过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就能统一处理所有代码规范问题。

3. 创建Prettier配置文件 (

   .prettierrc.json

   )： 在项目根目录创建此文件，定义你的格式化偏好。例如：

   {   "semi": true,   "singleQuote": true,   "tabWidth": 2,   "trailingComma": "all",   "printWidth": 100 }

   这些设置决定了分号、单引号、缩进宽度、尾随逗号和行宽等格式细节。

4. 创建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来处理所有格式化问题。

5. 配置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也会尝试修复它能自动解决的代码质量问题。

6. 添加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需要协调的地方。

它们如何协同工作？

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

解决这个问题的方案是：

1. eslint-config-prettier

   ：这个插件的作用就是“劝架”。它会禁用所有ESLint中与Prettier冲突的格式化规则。这样一来，ESLint就不再插手代码风格，把这个任务完全交给Prettier。

2. 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

文件中完成。

1. 覆盖继承的规则： 在

   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"

   (错误，会阻止提交)。

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

3. 针对特定文件或目录的规则： 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错误无法自动修复，提交就会被阻止，确保只有符合规范的代码才能进入仓库。这招非常有效，能从源头上保证代码质量。

定制化规则是一个持续的过程，随着项目的演进和团队的成长，你可能需要不断调整这些配置。但有了这些工具，这个过程会变得可控且高效。