一個完整的開源庫必須包含

• 文檔
• 好的編譯需求
• 規範
• 測試
• 持續集成

規範

對於會有很多人參與開發的專案，通常會有一份規範，請大家遵守常見的規範有:

1. 編譯器規範

   • 在不同執行的環境，不同編譯器運行在同一個專案時。因為不同的編譯器處理不同的操作時預設方式會不一致，因此需要統一操作的規範。例如tab 縮排有的是4格，有的是2格。結尾換行的時候 windows使用的是 crlf ，而 mac 和 linux 使用的是 lf，所以通常會使用 .editorconfig 進行規範。

   以下為範例

   root = true
   
    [*]
    charset = utf-8           //設定 字符集為 utf-8
    indent_style = space      //縮排方式使用 建議選space
    indent_size = 2           //縮排2個空格
    end_of_line = lf          //換行方式統一為LF
    insert_final_newline = true  //儲存檔案時在最後新插入一行
    trim_trailing_whitespace = true  //去掉行尾的空白字元
   
    [*.md]  //md檔案
    insert_final_newline = false  //儲存檔案時在最後新插入一行
    trim_trailing_whitespace = false  //去掉行尾的空白字元
   

2. 代碼風格規範

   • 通常我們會有一個代碼檢查小精靈 -- Linter，Linter 會幫我們做靜態語法的分析，在程式執行之前抓出可能的錯誤。更能確保我們的程式碼品質在一定的水準之上，在眾多的Javascript Linter中，推薦使用ESLint喔!

   • Linter 主要有幾個功能

     1. 找出語法錯誤 (ex:變數沒宣告，括號沒刮)
     2. 提醒你刪掉多餘的程式碼 (ex:有些變數宣告了卻沒有使用、import 了沒有使用的模組)
     3. 遵循最佳實踐 (ex:使用 === 而非 ==、不使用 eval)
     4. 直接幫我們的整理代碼 (超強大) (ex: 直接幫我們依照設定整理好代碼)

   • ESlint 使用方式:

     1. 下載 npm install eslint -g 全域下載
     2. 終端機 輸入 eslint --init 之後會有幾個問題，可以選擇自己的制定方式喔。設置完後會多一個 eslintrc.js 檔案
     3. 以下稍微解釋一下初始化後的文件

     //eslintrc.js
     
     module.exports = {
       root: true,
       parserOptions: {
         // 這是指 parser 要怎麼把你的程式碼切成 AST（抽象語法樹），這裡會涉及到一些語法分析、詞語分析方面的知識。
       },
       env: {
        // env 是指要在哪些環境執行，譬如說如果你的程式沒有要在瀏覽器執行，那就不應該有 window 或是 document 物件，ESLint 會幫你挑出這些錯誤
       },
       plugins: [
         // 一些資源Eslint的外掛套件，像是 react、flowtype...等。
       ],
       extends: [
         //通常會有 "eslint:recommend"這行代碼， 這是代表使用推薦的 ESLint 設定，可以看![ESLINT官方解釋](https://eslint.org/docs/rules/)裡面打勾的就是他的推薦設定喔。
       ],           
       rules: {
         // 如果上面的 extends 或是 plugins 有你不想要的規則，這時候就可以用 rules 把它蓋掉
       }
     }
     

3. 設計規範

   • eslint只能夠保證代碼規範，卻不能保證提供優秀的API設計。而每個專案也都會有自己的規範，例如: 函數裡面最多放五個參數，小駝峰命名(前端開發規範:https://www.itread01.com/content/1548431105.html)....。

4. 版本規範

   • 通常參考社群通用的語義化版本(https://semver.org/lang/zh-CN/)
   • 主要重點為:
     • 版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：
       • 主版本號：當你做了不兼容的API 修改。
       • 次版本號：當你做了向下兼容的功能性新增。
       • 修訂號：當你做了向下兼容的問題修正。
       • 先行版本號及版本編譯元數據可以加到“主版本號.次版本號.修訂號”的後面，作為延伸。

5. Git commit規範

   • 在多人協作的項目中，如果Git的提交說明精準，在後期協作以及Bug處理時會處理的容易一些，項目的開發可以根據規範的提交說明快速生成開發日誌，從而方便開發者或用戶追蹤項目的開發信息和功能特性。

     • 代碼提交規範化的目的
       • 為了部門提交代碼信息格式規範化
       • 為了更好的追溯代碼、篩選
       • 為了更加快速的定位提交代碼所涉及的範圍和實現功能
       • 為了後續代碼的Review、自動生成ChangeLog
     • 詳細可參考
       • conventionalcommits(https://www.conventionalcommits.org/zh-hant/v1.0.0-beta.4/#%e8%a6%8f%e7%af%84)
       • 規範化團隊git 提交信息(https://zhuanlan.zhihu.com/p/115372861)

總結

雖然這些規範相對於撰寫代碼有些無趣，但是他卻能大大保證library品質

參考資料:

• 8102年如何寫一個現代的JavaScript庫(https://juejin.im/post/6844903687819640845)
• JavaScript庫架構實戰(https://codertw.com/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/698450/)