使用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项目格式化工作流，通常涉及以下几个步骤：
安装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需要协调的地方。
代码小浣熊
代码小浣熊是基于商汤大语言模型的软件智能研发助手，覆盖软件需求分析、架构设计、代码编写、软件测试等环节
51 查看详情 
它们如何协同工作？
关键在于避免“内讧”。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错误无法自动修复，提交就会被阻止，确保只有符合规范的代码才能进入仓库。这招非常有效，能从源头上保证代码质量。
定制化规则是一个持续的过程，随着项目的演进和团队的成长，你可能需要不断调整这些配置。但有了这些工具，这个过程会变得可控且高效。
以上就是如何在VSCode中格式化TypeScript代码？配置TSLint和Prettier的指南的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/458201.html
微信扫一扫 
支付宝扫一扫 
