多人协作中统一的代码风格有利于项目的发展这是共识，但是采用什么标准来统一代码这选择就相对纷杂。项目刚开始使用了ESLint来规范代码，但是ESLint默认是支持JavaScript，加上配置可以支持TypeScript，而样式的支持则需要再配置StyleLint，所以后面在项目中引入了Prettier这个统一的方案。
因为最开始使用的ESLint的standard来规范JavaScript和TypeScript代码所以切换到Prettier的时候不方便做大的改动，所以Prettier的采用目的是规范JavaScript和TypeScript脚本之外的文件，例如：CSS | LESS | HTML | JSON | Markdown等文件。
但是在使用Prettier的时候出现了如下问题：
No parser and no filepath given, using 'babel' the parser now but this will throw an error in the future. Please specify a parser or a filepath so one can be inferred.
这个问题的描述其实很清楚了，就是说需要指定一个parser或者提供一个文件名来帮助Prettier推断使用哪个parser。这个问题是我在使用Prettier的api的时候发现的，我的使用方式是prettier.check(source, config)这里的srouce是一个string类型这是源码，源码直接提供给Prettier，那么这个source到底是什么类型的文件Prettier并不清楚，是JavaScript呢还是CSS呢还是其他的什么呢？这时候需要在第二个参数config中给Prettier提供一个filepath字段给Prettier推断源码类型的线索，这样就解决了这个问题。
Prettier有什么好处？
在Prettier的官网有介绍Prettier的好处以及与lint的区别，总结如下：
Prettier是一个固执的武断的样式格式化工具，怎么理解这句话呢？
Prettier是一个有主见的代码格式化工具，不会像ESLint一样给你很多配置项，让你去选择。Prettier的格式是固定的，只有少部分可以配置，并且这些配置也是因为一些不可抗力保留下来，可以预见的是这些配置不会急剧扩展，因为每增加一个配置就离Prettier减少样式争论的初衷越远。
Prettier不会修改AST
Prettier做的事情只是print，也就是将AST根据自己的规则打印出来，并且Prettier是从头到尾打印整个AST，而不是遇到一个节点判断是否合理，不合理就改掉，合理就保留，它是打印整个AST，从头到尾。
Prettier不会告诉你哪里错了
Prettier不会告诉你哪个语法不符合规范，然后在编辑器中标红，然后告诉你怎么改，而是直接帮你格式化。在使用prettier --check检查文件时也不会直接告诉哪里有问题，而是告诉你哪些文件没有没有运行Prettier，其实这就意味着你只要运行了Prettier那么就不会存在这个问题。但是用过ESLint的同学都知道ESLint的--fix可不是这样的，很多问题修复不了，需要自己手动修复。
Prettier只关注代码风格
相对于ESLint既关注代码风格也可以关注代码质量（例如：标识符声明了没使用，var 转const等）来说Prettier只关注代码风格，不关注代码质量，所以需要代码质量控制还是需要配合lint类工具。
Prettier因为只做代码风格检查所以可以没有上下文，也就意味着可以检查代码片段，也就是说 a = 1 这样的代码Prettier是可以通过。但是在ESLint中这个代码片段是不合法的，因为在使用a的时候必须要先声明标识符a。通过Prettier的这个特性就可以真正的实现代码风格的增量检查，而不是文件的增量检查。
Prettier支持很多语言风格指导
Prettier不只包含了JavaScript和TypeScript的代码风格还有很多其它语言的风格，上面就提到了CSS | LESS | HTML | JSON | Markdown还有很多其它语言的扩展。