eslint 保存自动修复_ESLint 自动修复问题之如何保留最后修改人信息

在推行代码规范的时候，绝大多数情况下都会遭到不小的阻力，一来每个人的代码习惯不一致，要人轻易改变习惯确实也不是一朝一夕的事情，二来一般都会带来额外的开发成本和其它困扰。我们不禁在想，推行代码规范的困难点在哪里，以及如何解决这些痛点，让各个角色更容易接受呢？

归纳起来，推行规范的过程中，最常听到的几点担忧有：

是否带来额外的开发成本

规范的执行力度有强制性吗

已经开发的分支，合入的时候遇到大量冲突谁来解决

存量代码如何解决

被修复的代码，后面一看最后修改人全部都是运行 eslint --fix 的那个人怎么办

根据经验，有以下的解决办法：

规范已经集成在编辑器里，开发的时候就已经能够发现问题，对于是否有分号的这种问题，工具能修复的，就不用花大力气去讨论谁是谁非的问题。并且配置好，在 commit 的时候就尽可能地自动修复问题，除非是真正的问题，并且工具不能自动修复的才需要人工修复。

将代码 MR 加入流程自动扫描，并且设置质量红线，有引入新问题的，就禁止合入

先合并修复分支，冲突部分全部选择自己的改动，在解决冲突后要 commit，因为配置了 lint-staged，那么这些冲突的文件在合并上去的时候又会被自动修复，这样就达到了合并和修复的双重目的

存量代码要不要解决，答案当然是要的，但是就会带来第 5 个问题，修复的代码丢失了最后修改人的记录怎么办࿰