TAT.SigmaLiu ESLint 自動修復問題之如何保留最后修改人信息
In 未分類 on 2020年03月06日 by view: 5,463
1

在推行代碼規范的時候,絕大多數情況下都會遭到不小的阻力,一來每個人的代碼習慣不一致,要人輕易改變習慣確實也不是一朝一夕的事情,二來一般都會帶來額外的開發成本和其它困擾。我們不禁在想,推行代碼規范的困難點在哪里,以及如何解決這些痛點,讓各個角色更容易接受呢?

 

歸納起來,推行規范的過程中,最常聽到的幾點擔憂有:

  1. 是否帶來額外的開發成本
  2. 規范的執行力度有強制性嗎
  3. 已經開發的分支,合入的時候遇到大量沖突誰來解決
  4. 存量代碼如何解決
  5. 被修復的代碼,后面一看最后修改人全部都是運行 eslint --fix 的那個人怎么辦


根據經驗,有以下的解決辦法:

  1. 規范已經集成在編輯器里,開發的時候就已經能夠發現問題,對于是否有分號的這種問題,工具能修復的,就不用花大力氣去討論誰是誰非的問題。并且配置好,在 commit 的時候就盡可能地自動修復問題,除非是真正的問題,并且工具不能自動修復的才需要人工修復。
  2. 將代碼 MR 加入流程自動掃描,并且設置質量紅線,有引入新問題的,就禁止合入
  3. 先合并修復分支,沖突部分全部選擇自己的改動,在解決沖突后要 commit,因為配置了 lint-staged,那么這些沖突的文件在合并上去的時候又會被自動修復,這樣就達到了合并和修復的雙重目的
  4. 存量代碼要不要解決,答案當然是要的,但是就會帶來第 5 個問題,修復的代碼丟失了最后修改人的記錄怎么辦,所以終究還是要解決的是第 5 個問題。

 

那么我們考察市面上是否有解決方案

難道真的沒有解決辦法了嗎?

我們研究了 ESLint 的修復流程

發現是不是只要定制化輸出報告就可以針對指定人員做修復?

 

那么讓我們看一下報告都有哪些信息。

  • line: 待修復的代碼開始行
  • endLine: 結束行
  • range: 修復的代碼位置
  • text: 變更后的代碼片段

那么是否只要判斷 line 和 endLine 在文件里相應位置的作者信息,用一個數組的 filter 就可以解決了?然后發現實際上并不生效并且還有錯誤。因為:

  • 修復只是將 output 里的代碼替換掉整個文件
  • messages 里的項是線性疊加的,后面一項是依賴于前面一項的。也就是當前項的 line 和 endLine 是根據上一項修復的結果。如果前面有一項有行列變動的話,那么當前的修復也跟原文件是對應不上的。

 

問題好像又回到了無法解決的原點。在仔細研究了 Node.js API 文檔后,我們發現有趣的一句話:

fix - This can be a boolean or a function which will be provided each linting message and should return a boolean. True indicates that fixes should be included with the output report, and that errors and warnings should not be listed if they can be fixed. However, the files on disk will not be changed. To persist changes to disk, call outputFixes().

意思是 fix 參數是支持函數的,messages 只是包含每個收集到的可修復信息,但是會視 fix 返回值來決定是否將可修復信息真的應用到修復上,也就是是否會在 output 上體現。

這就給我們帶來了可操作的空間,在 fix 函數里去判斷是否是相關聯作者,如果是就返回 true,如果不是就返回 false。大概的流程是這樣的:

以及看一下相關代碼

在我們過濾了指定人員的修復報告后,只需要循環按人員來修復就可以了,用 git commit -m "xxx" --auth "auth " 來保存修改人信息

最后是我們達到的效果,比如有個文件的內容和修改人信息如下:

經過工具修復后:

可以看到 14 - 16 行,27 - 29 行即使有行變動,依然能完整保留最后修改人的信息。

 

git blame 工具仍維持著原修改人

 

編輯器里看到的也是經過我們處理過的最后修改人

 

git log 上看到的也都是按每個修改人去做的自動修復記錄

在?git blame --line-porcelain 能同時看到修改人和提交人

至此,我們可以說我們已經有了解決這個問題的完整方案,并且切實可行。我們將工具開源到 github 上,制作發布了 npm 包,歡迎試用和提問題。

AlloyLint

AlloyLint

原創文章轉載請注明:

轉載自AlloyTeam:http://www.ecomenagepro.com/2020/03/14286/

  1. 宗麒麟 2020 年 4 月 17 日

    又來拜讀 Alloyteam 大作,熟悉的配方,熟悉的味道

發表評論