參與前端開源項目你應該瞭解的知識

引言

在很早之前，開源軟件的開發並不受待見，甚至受到排擠，廣泛認爲軟件是商業性質的產物，開源沒有任何利益，也沒有一個很好的平臺去分享本身的技術成果。現在，觀念發生了轉變，認爲開源更易於發現問題，解決問題，促進技術交流，技術升級，技術創新，而且能推進公司業務的發展。隨着大型同性交友平臺Github的誕生，吸引了全球範圍內無數的開發人員共同參與到開源項目中，開發者能夠自由的建立項目，分享代碼，共同合做完成一個項目。近幾年，Github開源項目數量呈指數型增加，已然成爲一個趨勢，尤爲是JavaScript脫穎而出，成爲了毫無疑問的最熱門語言，本文談談參與一個前端開源項目你須要瞭解並具有哪些知識。

包管理器

社區中幾乎每個開源項目都是採用NPM做爲包管理器，固然也有一小部分使用了Bower包管理器，比較新的項目則採用Yarn來替代NPM管理模塊。

NPM & Yarn

NPM生成的入口文件是package.json，須要指定必要的基本信息，以及編寫npm run快捷腳本命令。

• name決定模塊的名稱，不容許與npm社區中的已發佈模塊同名，模塊發佈後，其餘開發者能夠經過該名稱安裝該模塊。
• version需遵循語義化版本規範，格式爲[MAJOR].[MINOR].[PATCH]，分別表明主版本，次版本，補丁版本，能夠經過執行npm version命令自動更替版本。
• main表示模塊的入口文件，用戶經過require('example')加載該入口文件。
• license聲明版權類型，如果私有項目，則設置"license": "UNLICENSED"或者"private": "true"，這種狀況下，執行npm publish發佈模塊將會失敗。
• scripts用於編寫自定義npm腳本命令，一般上包括開發、編譯、打包構建、測試、格式檢查、文檔構建等經常使用腳本命令，對於複雜腳本命令，能夠單獨寫在shell腳本文件裏，通常放在根目錄下scripts文件夾中。

一個基本的package.json示例以下：

{
  "name": "example", "version": "1.0.0", "description": "This is an example project", "keywords": [ "example" ], "main": "lib/index.js", "scripts": { "dev": "webpack --config webpack.dev.config.js", "build": "webpack --config webpack.prod.config.js", "lint": "eslint src", "test": "mocha *.test.js", "docs": "gitbook build", "clean": "rm -rf ./dist", }, "dependencies": { }, "author": "xxx", "repository": { "type": "git", "url": "https://github.com/xxx/xxx.git" }, "license": "MIT" }

自動化構建及模塊打包器

Gulp/Grunt屬於自動化構建工具，是爲了解決前端工程化中重複性、繁瑣性的工做如配合第三方插件進行編譯、壓縮、合併、複製等文件操做。而Webpack/Rollup/Browserify定位是模塊加載兼打包器，支持打包AMD/CMD/COMMONJS/ES6/HASTE/UMD等模塊規範，隨着生態的壯大，插件機制愈來愈豐富，愈來愈完善，在某些場景下已經徹底能夠取代Gulp/Grunt的工做。

ES6+Webpack+Babel

老項目仍採用Gulp+Webpack等雙機制構建，主流項目採用純粹的Webpack結合各類loader插件及配置打包構建。現在，Webpack生態和Babel生態受到了愈來愈多開發者的青睞，具有可配置性高、可擴展性高、功能豐富強大等特色，開發者能夠自由地制定插件及引用第三方插件，二者協同工做，能夠盡情地體驗ES6/7/8的開發。

測試

一個大型可靠的開源項目離不開測試，測試能夠幫助開發人員及時發現問題，定位問題，提升代碼質量，保證輸出結果的正確性，避免缺陷迴歸，減小每次修改代碼後人工review大量代碼的成本，可分爲測試驅動開發(TDD)和行爲驅動(BDD)開發兩種類型。另外一方面，開發者不只能夠經過閱讀文檔還能夠經過閱讀測試用例來看懂程序的功能，尤爲是當一個項目愈來愈龐大，邏輯愈來愈複雜，就須要根據測試用例經過與否、測試覆蓋率等指標來衡量項目的質量。

• 測試執行工具：Karma
• 測試框架：Mocha/Jasmine/QUnit/AVA/Jest/Enzyme
• 斷言庫：Chai/Expect/Should/Assert
• 覆蓋率：Coveralls/Codecov/Istanbul/Isparta

Karma+Mocha+Chai

Karma是一個測試執行過程管理工具，原名Testacular，該工具主要做用是讓測試用例跑在全部主流瀏覽器如Chrome/Firefox或者無界面瀏覽器PhantomJS上，因此若是你的代碼是設計在瀏覽器上的，那麼使用Karma的測試結果更貼近真實環境。
測試框架有不少，從NPM下載量上來看，Mocha是下載量最高的測試框架，它能夠同時運行在瀏覽器和Node端，Mocha自己不帶斷言庫，擴展性高，支持異步測試，須要結合第三方斷言庫如Chai(支持TDD/BDD)實現單元測試。
測試覆蓋率是一項衡量測試用例設計好壞的硬性指標，如可使用覆蓋率統計工具Istanbul結合測試框架Mocha進行測試，自動分析、記錄並保存測試結果，生成測試報告，最後經過Coveralls上傳至遠程服務器。

Linter

一個大型可靠的開源項目也須要統一代碼風格，強調代碼質量，遵循同一套規範標準，例如縮進格式，是否使用分號等等，其直接影響了項目的可維護性，合做性。所以，就須要引入Linting工具來檢查約束代碼格式，各大公司也紛紛制定了本身的Javascript編碼規範，如Google/Airbnb/Clean Code等等。固然，每一個項目代碼風格各不相同，蘿蔔青菜，各有所愛，這徹底取決於項目維護者的偏好！

King of Linter

目前Linter工具主要有ESLint/JSCS/JSHint/JSLint等等。ESLint毫無疑問已經成爲最主流的Linter，提供了豐富的插件，可配置性很高，支持JSX語法，生態愈來愈完善。ESLint的優勢是徹底插件化，每個規則都是一個插件而且你能夠在運行時經過註釋添加更多的規則，或者禁用某項規則。此外，執行eslint --fix命令可快速修復部分常見可自動修復錯誤，便捷快速強大，開源項目必備。

持續集成

持續集成在開源項目中不可或缺，每次代碼提交或PR後都會在持續集成服務器上觸發一次自動化測試構建部署，確保開發人員對項目源碼做出的更改不會致使程序發生錯誤，減小了風險，增長了項目的可靠性。

Travis CI

目前，前端項目中比較流行的持續集成工具備TravisCI/CircleCI/AppVeyor等等，配置文件通常是一個YAML文件。以Travis CI爲例，須要在根目錄下建立一個.travis.yml文件，並指定一些基本配置信息，例如語言、運行環境、執行腳本命令、啓用緩存、分支選擇等等，當指定分支代碼提交後，持續集成環境將會讀取該文件並執行相關指令，最後將是否構建成功的結果反饋給用戶。

一個Travis配置文件示例：

sudo: false
language: node_js
node_js:
  - "4" - "5" - "6" cache: directories: - node_modules script: - npm run lint - npm run test - npm run build after_script: - coveralls < ./coverage/lcov.info branches: only: - master

靜態網站生成器

每個龐大的開源項目必然有詳細的文檔介紹和示例演示，但僅僅依靠README.md文件侷限性太大，篇幅不夠長，不足以直觀地展現全部內容。另外一個方案是手動編寫一系列HTML文件，每個HTML文件都包含一系列CSS文件、JS文件，最後部署到本身的服務器或Github Pages網站上。可是，當項目愈來愈龐大，愈來愈複雜，時間成本、人力成本將會大幅度增長，開發者不得不花大量精力去維護站點，沒法專一於業務編碼。正因爲這種緣由，催生了靜態網站生成器的快速發展與普及使用，你能夠在StaticGen上找到目前較爲流行的靜態網站生成器。

Jekyll

靜態網站生成器都有一些共同特色，支持markdown格式，更好得適應文檔的編寫，將網站組件化、模板化，複用公共組件，消除重複組件，而且包含一個資源管道，用於處理資源編譯、轉譯、打包、壓縮。除此以外，靜態網站生成器還會提供一個命令行功能用於在本地服務器構建網站進行實時預覽。在項目中，通常把文檔放在根目錄下docs文件夾中。

必備文檔

README.md

開源項目的門面，讓用戶第一時間瞭解該項目具體是作什麼的，一份好的README文件應包含但不只限於項目標題、描述、徽章、主要內容、如何安裝、如何使用、API文檔、如何參與貢獻、版權類型等等內容。

CHANGELOG.md

用於記錄每一次版本升級後的更新說明，包括Bug修復、新功能等等，通常和項目新Tag一塊兒發佈。

CODE_OF_CONDUCT.md

行爲守則是一套我的或組織參與開源項目所必須遵循的規則，規範，公約，大多數項目都是採用Contributor Covenant規則。

CONTRIBUTING.md

全方位指導你如何參與貢獻代碼，如何進行本地開發，如何提ISSUE，如何提PR等等，參與項目前必看的文檔。

ISSUE_TEMPLATE.md

ISSUE模板，提ISSUE時Github自動識別讀取注入。

PULL_REQUEST_TEMPLATE.md

PR模板，提PR時Github自動識別讀取注入。

LICENSE

聲明項目所遵循的版權類型

其它

目錄規範

常見目錄結構及文件說明，如下只列出一部分，實際項目可變通

root/                
├── .github/                # ISSUE&PR模板文件夾 ├── bin/ # 命令行指令入口文件夾 ├── build/ # 工程配置類文件夾 ├── dist/ # 打包輸出後的產品文件夾 ├── docs/ # 文檔文件夾，最終被靜態網站生成器編譯 ├── examples/ # 使用示例文件夾 ├── packages/ # 子模塊文件夾 ├── lib/ # es編譯後的輸出文件夾 ├── scripts/ # 腳本命令文件夾 ├── src/ # 源代碼文件夾 ├── test/ # 測試文件夾 ├── .babelrc # babel配置文件 ├── .editorconfig # 編輯器配置文件 ├── .eslintrc # ESLint配置文件 ├── .eslintignore # ESLint忽略文件 ├── .flowconfig # Flow配置文件 ├── .gitattributes # Git屬性配置文件 ├── .gitignore # Git忽略文件 ├── .npmignore # NPM忽略文件 ├── .stylelintrc # StyleLint配置文件 ├── .travis.yml/circle.yml # CI環境配置文件 ├── CHANGELOG.md/History.md # 版本更新說明文件 ├── CODE_OF_CONDUCT.md # 行爲守則說明文件 ├── CONTRIBUTING.md # 貢獻指導文件 ├── AUTHORS # 貢獻者列表文件 ├── LICENSE # 版權聲明文件 ├── PATENTS # 專利聲明文件 ├── README.md # 自述文件 ├── Makefile # Make命令文件 ├── Gruntfile.js # Grunt配置文件 ├── gulpfile.js # Gulp配置文件 ├── karma.conf.js # Karma配置文件 ├── webpack.config.js # Webpack配置文件 ├── rollup.config.js # Rollup配置文件 ├── bower.json # Bower入口文件 ├── package.json # NPM入口文件 └── yarn.lock # Yarn生成的模塊記錄文件

結尾

不管你是小白或是大牛，但願讀完此文能讓你有所收穫，能夠對開源項目的結構、模式大體有所瞭解。實際上，一個大型的開源項目每每要面臨和解決各類各樣的問題，項目的維護者須要付出不少的時間與精力。近幾年，開源項目的產出速度愈來愈快，不斷涌現新框架、新工具、新庫，但國內優秀的開源項目仍舊爲數很少，大部分只是在造輪子，任重而道遠，與此同時，咱們更應該注重開源項目的質量，也但願更多的人蔘與到開源項目中。