代码美化神器——Prettier使用详解

由于团队开发人员的编码习惯较难统一，要做到代码风格的一致性相对困难，尽管可以讨论制定代码规约，但可能会给开发带来额外的烦恼。Prettier的出现，很好地解决了这个问题，还可以搭配Git的hooks规避不合规范的提交

这是我参与更文挑战的第1天，活动详情查看： 更文挑战

为何使用Prettier

多人协作的项目开发中，保持统一的代码风格是一件很重要的事。

可团队里总有一些不服管的刺头，说什么也不愿意被约束，怎么开心就怎么来！

可是统一代码风格后的好处又非常明显：

• 整齐的步伐
• 更少的垃圾代码（漂亮的格式意味着更好维护的代码）
• 基于以上两点，更强的团队战斗力

所以，我们需要一个工具将我们散漫的风格迥异的代码格式化为符合规范的代码。Prettier正好可以做到这一点。 它的工作原理是将代码解析成AST，再结合内置的一些规则，还原格式化后的代码

如何使用

prettier可以通过以下方式使用

• 安装编辑器配套的插件，在编辑器内配置一下即可使用:详情
• 安装官方的CLI工具，使用cli工具提供的命令
• 编程的形式使用：通过调用npm 包prettier暴露的一些模块或方法（需要说明的是，prettier也支持在浏览器端格式化代码）

第一种方式的优点是：配置简单，使用方便，可以搭配快捷键（ctrl+s保存 触发自动格式化），然而每个人可能使用不同的编辑器，版本、配置不好统一，很难预设一份配置表给所有人共享。所以个人使用没问题，团队推广不太适合。

第二种方式，prettier作为开发依赖记录在package.json里，跟着项目走，版本统一，既可以使用官方的默认配置，也可以指定一套内容的配置项。适合团队协作。

第三种方式，适合一些搭配prettier的API写一些代码嵌入到一些特定的代码中执行。

大多数我们还是用到的第二种，这里我们介绍第二种方式：

• 安装依赖： npm install prettier -D
• 在目录下新建一个文件test.js:

//格式故意搞乱，不对齐！
function uglyCode () {
console.log("this is an ugly function!") 
 }

• 运行命令：npx prettier --write .\test.js,发现代码被格式化了：

function uglyCode() {
    console.log('this is an ugly function!');
}

当然我们也可以不指定具体文件名，直接运行npx prettier --write . ,表示格式化当前目录下的所有文件（测试发现html、css、js、ts、jsx文件都会被格式化）。

注意：prettier默认不会处理node_modules里的文件，如果我们想忽略其他的文件或目录，可以在项目目录下新建.prettierignore文件，表示忽略某些文件或文件夹，具体格式跟.gitignore类似.

目前的代码格式化都是Prettier根据自己的默认配置帮我们做的，当然我们也可以通过Prettier的配置项实现自定义的格式需要

Prettier的配置项

说到自定义配置项，我们需要在项目根目录新建一个.prettierrc的文件，格式为json，结构如下：

{
    "配置项名称": "配置项的值"
}

其实凡是符合cosmiconfig的配置都可以:json文件啦，yaml文件啦等等。

主要有以下项：

• printWidth. 条件允许时每行字符长度大于该值时进行换行（prettier不会强行换行：比如将一个引号包裹的字符串折行）。默认为80
• tabWidth. 缩进空格数；默认为2
• semi. 语句末尾是否带分号
• singleQuote. 是否将双引号转换为单引号。双引号里包含单引号时不会被格式化。
• quoteProps. 对象属性引号的配置
• jsxSingleQuote. jsx文件里使用单引号
• bracketSpacing. 圆括号之间添加空格，如{ a: b }
• arrowParens. 箭头函数，参数添加圆括号，如(x)=>y
• parser. 指定解析器，我们一般不需要默认的就行
• 等等

具体可以查看文档

Git集成

目前，我们已经配置好了prettier的项，接下来就剩运行格式化的时机了，什么运行最好呢？当然是代码提交的时候。

我们需要在开发提交代码时，运行prettier格式化staged的代码，之后再提交，这就需要用到Git Hooks了，不过已经有工具帮我们集成了，我们只需安装并简单配置以下即可。 这里介绍两种：

pre-commit

• 安装依赖：npm install pre-commit -D
• 配置脚本：

//package.json
{
  "scripts": {
    "prettier": "npx prettier --write ."
  },
  "pre-commit": ["prettier"]
}

完成安装和配置后，当开发者完成代码，执行git add 文件名或路径后（即stage改变）的时候，会自动运行配置的prettier脚本，执行格式化，开发再将格式化后的新改变添加最后提交即可。

这种方式优点是配置比较简单并且看得到改变（指格式化后的结果），缺点是如果开发不按规矩来，拒绝添加格式化后的代码（无意或有意）那么问题依然存在。

lint-staged

• 安装依赖 npm install mrm@2 -D
• 通过mrm安装lint-staged:npx mrm lint-staged

注意： lint-staged包指定mrm的版本为2，这个包是帮助开发者初始化配置的，当你安装并运行完上述命令后你会发现：

• package.json里多了两个开发依赖（husky和lint-staged）和一个prepare的脚本:

{
    "scripts": {
        "prepare": "husky install"
    },
    "devDependencies": {
        "husky": "^6.0.0",
        "lint-staged": "^11.0.0",
        "mrm": "^2.6.2",
        "prettier": "2.3.0"
    }
}

• 根目录多了一个.husky的文件夹

接下来将某个文件搞乱，然后git add 这个文件,最后提交:git commit -m "first test"，你会发现你提交的代码是格式化后的，你竟然没有任何的感知。很好玩吧？

这种方式的优点是可以有效避免了开发人员的误操作，缺点是一切浑然不觉（当然也是优点）。

综合上述，我个人更推荐第二种集成方式。

最后

如果你读到了这里，感觉本文对你有帮助，麻烦点个赞，鼓励作者写出更多更高质量的文章，谢谢。

如果你对Prettier有任何的疑惑，也欢迎留言讨论哦！