不推荐使用 Prettier

绝命小金:
第一，那个数组元素换行问题可以配置 printWidth，例如配置为 100，如果你加了几个单词后又超出了，可以继续增加 printWidth 的值。 第二，对于你说的第二种情况，需要存一些数据，然后呈现特殊的格式，比如每三个元素换行。可以使用 // prettier-ignore 注释，这个注释后一段代码不会被执行格式化，而且不影响更后面的代码格式化，只是加这个注释有点不优雅。

【回复】兄弟，这你觉得意义在哪呢，无限加了呗
【回复】回复 @程序员青杨 :确实不优雅，很麻烦
sully_T:
完全在胡说八道，prettier 的本质是开箱即用与标准化

【回复】任何开箱即用不都是默认配置嘛 它标准化又怎么说呢
水果味的C:
prettier的配置没法解决这个问题么？[惊讶]如果缺少相关配置的话这不是个pr的机会么。

【回复】回复 @程序员青杨 :看了下，Prettier 解决视频中的问题只能通过 `// prettier-ignore` 这种行内注释解决，因为在 Prettier 的设计中 print width 是作为代码格式化算法的输入，而非一个规则。 我平时确实也都只使用 ESLint，貌似从 2017 ESLint 4.0 版本支持 autofix 功能起，ESLint 就一不小心逐渐代替了 Prettier 的大部分功能。
【回复】目前是没法从根本上解决的。如果为了一个又一个的需求，加了更多的配置，最终就变成ESLint了
【回复】回复 @水果味的C :✌️ 确实如此
前端马赛克:
第一个问题：格式化后变动多，看似代码量增加，如果是以这个来衡量工作量，问题不是在格式化上，是规则制度上。并且作者的场景是在以后项目中使用格式化，新项目一开始就统一格式化不也很好吗。全部文件全部格式化后，以后就不会出现up主说的情况了，所以导致一行代码格式化变多行跟格式化优劣没关系。 第二个问题，每个格式化都会有利有弊，格式化存在是有意义的。第二种现象如果eslint好使，但也会有eslint格式化不好的场景，所以根本问题是要怎么配置解决这些问题，而不是直接否定prettier

【回复】首先，感谢你的讨论观点。我没有否定的意思，是不推荐。第一个问题，自动换行的问题是规则printWidth带来的，无论怎么设置都有可能会出现问题，是无解的。
哦哦哦o潘森:
[囧]说的对，我不知道你们用没用过vscode的一款插件，就是在文件头部声明作者，以及创建文件信息的注释，写完了一保存 Prettier直接把这些信息变成一行了杂乱无章。。。。就很无奈。。。。。。

【回复】一般不用这种插件，话说 prettier会格式掉这种注释吗，不应该吧
TRCYX:
我记得 prettier 自己就说自己是 opinionated，要是你喜欢它那套那可能也能算开箱即用，不喜欢感觉也正常，不应该有什么包袱。我个人也不太喜欢。用过的最听话的格式化还是 Scala 的 scalafmt。

扁担没有板凳长:
换行问题，你可以加空注释解决。 prettier优点是开箱即用，eslint要配半天，非风格类型的规则可能破坏源码

【回复】非风格类型的规则会破坏源码 这个怎么理解
blesstosam:
printWidth本身看作一种规范，就好像eslint的很多规范一样，用eslint配出来的规范也可能会被其他组员吐槽，本质上是每个人的编码风格不一致导致的，用eslint就能完美解决所有问题吗？我觉得也很难！

【回复】但是prettier自动换行确实给代码review带来了一点困扰
tocopy:
两套要，一套统一格式化，一套自己用

奇趣保罗:
第一行可以改配置，多少个字符才换行

【回复】回复 @程序员青杨 :我选择不用 Prittier [OK]
【回复】所以 print-width 我们要设置成多大呢
noah_qiao:
不过怎么说呢，好的工具也需要有会使唤的工人，既然自己玩不来还是别玩了，留给喜欢玩的人吧

【回复】😄 那有什么办法解决这个问题呢
日本国父麦克阿瑟:
prettier好像是开发组故意不做那么多配置，目的就是想让一套统一的标准约束程序员让所有人代码都是一个风格，很多提到他们GitHub上的增加配置项的issue他们都以理念为由不受理

扶不起的蝌蚪:
commit提交进行格式化就行了吧，就不会冲突了

铅笔first:
格式化标准不统一是真的难受，像第一种情况写个代码提交各种冲突，实际啥也没改徒增工作量

【回复】确实如此 现在项目只用eslint了
gudugudu:
请问博主，这个视频里代码智能提示插件是啥？[奥比岛_击爪]