這篇文章主要介紹“怎么實現git代碼規范”,在日常操作中,相信很多人在怎么實現git代碼規范問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”怎么實現git代碼規范”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
ESLint 與約束
統一編碼規范不僅可以大幅提高代碼可讀性,甚至會提高代碼質量。當我們設計了一套關于編碼規范的規則集時,需要工具去輔助檢測,這就是 ESLint。
$ npm install eslint --save-dev
規則集需要統一集中配置,ESLint 會默認讀取配置文件 .eslintrc 來解析,而規則集在 rules 中進行配置:
{ "rules": { "semi": ["error", "always"], "quotes": ["error", "double"] } }
而我們需要做的是設定我們的代碼規范,即 rules 項。
不要重復造輪子
我們需要推到重來,設計屬于自己團隊的一套編碼規范嗎?
完全沒有必要推倒重來,既耗費人力,又難以做到規則的全部覆蓋。
很多優秀的團隊,都根據最佳實踐設定了特別優秀的編碼規范,比如 airbnb 設定了一套約束特別強的規范。另外也有一些特別簡單但卻十分實用的規范,如 eslint:recommended。
airbnb javascript style[2]
我們僅僅需要使用 extend 配置項去繼承一些優秀的開源的代碼規范,并使用 rules 做一些自己團隊的規則補充。
{ "extend": ["airbnb-base"], "rules": { "semi": ["error", "never"] } }
開發環境,生產環境與警告
開發環境對于開發而言重要的是什么?
是開發體驗。
一個良好的編碼規范會帶來解放強迫癥的舒適感,但過于嚴格的代碼風格有時也會使人煩躁。試舉兩個小例子,有可能是在你寫代碼時出現過的場景:
禁止掉 console.log,避免在生產環境輸出多余的東西。但偏偏在測試環境經常需要調試,但是如果僅僅設為警告的話,警告又會被忽視,失去意義。
特別是當設置了規則 no-unused-vars 時。如果僅僅是為了在開發時調試,卻因為無法通過 ESlint 規則校驗無法方便調試。
這是一個約束與自由的權衡,ESLint 在提供強有力約束時自然會犧牲一些開發上的便利性。中庸,儒家思想講究中庸,此時可以在權衡下選擇一個中庸的方案:
把 ESLint 的所有影響調試的規則校驗都設置為 Warn,那你又問了警告往往不是會被忽略嗎?是這樣子的,所以需要在 CI 中設置環境變量 CI=true,如此在 CI 中即使有警告也無法交付。
如在 create-react-app 中的大部分規則都是設置為 Warn
但是,如果你使用了 webpack,并且結合 eslint-loader,那解決方案就更加簡單了:使用 emitWarning: true,在測試環境把所有 Error 都當做 Warn,這樣避免了修改 ESLint 規則,webpack 的配置如下:
{ test: /\.(js|mjs|jsx|ts|tsx)$/, enforce: 'pre', use: [ { options: { cache: true, emitWarning: true, }, loader: require.resolve('eslint-loader'), }, ] }
所以有兩種權衡開發體驗與編程規范的方式:
把 ESLint 的 rule 設置為 Warn,并在持續集成中配置環境變量 CI=true。
結合 webpack 與 eslint-loader,根據當前環境的環境變量配置 emitWarning。
第一層約束:IDE
當不符合代碼規范的第一時間,我們就要感知到它,及時反饋,快速糾正,比直到最后積攢了一大堆錯誤要高效很多。
這里以 VS Code 作為示例,它只需要安裝一個插件:eslint,便可以做到智能提示,來看看效果吧:
另外,配合 eslint-loader,使用瀏覽器也可以做到實時提示:
第二層約束:Git Hooks
團隊合作中的編碼規范有一點是,雖然自己有可能不舒服,但是不能讓別人因為自己的代碼而不舒服。
git 自身包含許多 hooks,在 commit,push 等 git 事件前后觸發執行。與 pre-commit hook 結合可以幫助校驗 Lint,如果非通過代碼規范則不允許提交。
husky[3] 是一個使 git hooks 變得更簡單的工具,只需要配置幾行 package.json 就可以愉快的開始工作。
(1) husky 的原理是什么?
// package.json { "scripts": { "lint": "eslint . --cache" }, "husky": { "hooks": { "pre-commit": "npm lint", } } }
或者結合 lint-staged[4] 調用校驗規則
{ "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.js|{lib,setup,bin,hot,tooling,schemas}/**/*.js|test/*.js|{test,examples}/**/webpack.config.js}": [ "eslint --cache" ], "*.{ts,json,yml,yaml,md}|examples/*.md": [ "prettier --check" ], "*.md|{.github,benchmark,bin,examples,hot,lib,schemas,setup,tooling}/**/*.{md,yml,yaml,js,json}": [ "cspell" ] } }
不過做前端的都明白,客戶端校驗是不可信的,通過一條命令即可繞過 git hooks。
$ git commit -n
第三層約束:CI
git hooks可以繞過,但 CI(持續集成) 是絕對繞不過的,因為它在服務端校驗。使用 gitlab CI 做持續集成,配置文件 .gitlab-ci.yaml 如下所示:
lint: stage: lint only: - /^feature\/.*$/ script: - npm lint
到此,關于“怎么實現git代碼規范”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。