如何構建自動化的前端開發流程
如今的前端開發中，已經不再只是一些簡單的靜態文件了，對于很多Web App來說，前端代碼甚至比后端代碼要更加復雜，更加難于管理，例如：
- 我們有許多的第三方庫的依賴需要管理；
- 我們有獨立的前端測試需要自動運行；
- 我們還有很多代碼需要在發布時進行打包壓縮；
- ⋯⋯
所以構建一個自動化的前端開發流程是非常必要的，但現在前端開發流程的構建是百花齊放，沒有一個統一的標準，還有很多依賴于后端的架構來做前端開發管理。例如在Rails開發中，就有各種前端庫的gem包。但是這種依賴于后端框架的管理方式有許多問題：
- 許多gem包的維護者并不是前端庫的維護者，所以更新不一定即時；
- 不利于前端代碼與后端代碼做分離；
- 增加了前端開發者的學習和使用成本；
- ⋯⋯
于是現在出現了一些不依賴于后端代碼（雖然還是要依賴Node.js⋯⋯）的管理工具，對于前端開發者非常友好，例如：YEMAN、Jam、volo、component、Brunch⋯⋯但是這些工具都或多或少有自己的一些問題，所以我決定用一些更輕量的工具（bower、grunt）來搭建自己的前端開發流程。本文的例子來自本人正在開發的一個項目，可以在github上查看所有的代碼。
什么是開發流程？
在我看來一個完整的開發流程應該包括：
- 本地開發環境的初始化
- 第三方依賴的管理
- 源文件編譯
- 自動化測試
- 發布到pipeline和各個環境
而現代的開發流程，就是要使上面的各個部分都可以自動化，一個命令就可以使這些流程都自動走完，并且快速的得到錯誤或通過的反饋，讓我們可以方便快速的修復錯誤和release。
本地開發環境的初始化
這里我使用的工具是Node.js和NPM，它們都基于JavaScript，使用Json來配置，對于前端開發人員非常友好。
安裝完成Node.js和NPM后，在項目根目錄下創建NPM的配置文件package.json：
- {
- "name": "Project Name",
- "version": "0.0.1",
- "description": "Project Description",
- "repository": {
- "type": "git",
- "url": "git://github.com/path/to/your_project"
- },
- "author": "Author Name",
- "license": "BSD",
- "readmeFilename": "README.md",
- "gitHead": "git head",
- "devDependencies": {
- "grunt": "latest",
- "grunt-contrib-connect": "latest",
- "grunt-contrib-concat": "latest",
- "grunt-contrib-jasmine": "latest",
- "grunt-contrib-watch": "latest",
- "grunt-contrib-compass": "latest"
- }
- }
其中最重要的一個配置項是devDependencies，這是用于開發的依賴，例如：自動化測試、源文件編譯等等，其中各個依賴的作用和用法將會在后面講到。而前端生產代碼的依賴會使用另一個工具來管理，也在后面講到。創建完成以后運行npm install，NPM就會將這些依賴都安裝到項目根目錄的node_modules文件夾中。
第三方依賴的管理
這里我使用的工具是bower。 其實NPM也可以管理，但是NPM并不是讀取第三方依賴原始的repository，而是讀取自己管理的一個repository，所以更新可能會慢點， 并且它使用CommonJS的接口方便Node.js項目的開發，并不是針對純前端開發的項目；而bower是讀取原始的github repository，沒有更新延遲的問題，所有包都是針對純前端開發項目的。
要使用bower只需要簡單的三步：
- 安裝：
npm install bower -g - 在項目根目錄中創建配置文件
.bowerrc - 在項目根目錄中創建依賴配置文件
components.json
我們首先來看看.bowerrc的內容：
- {
- "directory" : "components",
- "json" : "component.json",
- "endpoint" : "https://bower.herokuapp.com"
- }
其中directory指定了所有的依賴會被安裝到哪里；json指定了依賴配置文件的路徑；endpoint制定了依賴的repository的尋址服務器，你可以替換為自己的尋址服務器。
然后我們來看看components.json的內容：
- {
- "name": "Project Name",
- "version": "0.0.1",
- "dependencies": {
- "jquery": "latest",
- "underscore": "latest",
- "backbone": "latest",
- "jasmine-jquery": "latest",
- "jasmine-ajax": "git@github.com:pivotal/jasmine-ajax.git"
- }
- }
其中最重要的就是dependencies，它指定了所有前端開發依賴的包。所有bower包含的依賴都可以在這里查到，對于bower沒有包含的依賴也可以直接指定github的repository，例如："jasmine-ajax": "git@github.com:pivotal/jasmine-ajax.git"。
最后運行bower install就可以在components文件夾中看到所有第三方依賴的文件了。但是bower有一個問題，就是它將所有github repository中的文件都下載下來了，其中有許多是我們不需要的文件。下面我們會將我們需要的文件提取出來打包放到我們指定的目錄中。
#p#
源文件編譯
這里我使用的工具是grunt，他本身主要是基于Node.js的文件操作包，其中有許多插件可以讓我們完成js文件的compile和compress、sass到css的轉換等等操作。要使用它需要先安裝命令行工具：npm install grunt-cli -g，然后在項目根目錄中創建文件Gruntfile.js，這個文件用于定義各種task，我們首先定義一個task將從bower下載的第三方依賴都打包到文件app/js/lib.js中：
- module.exports = function(grunt) {
- var dependencies = [
- 'components/jquery/jquery.js',
- 'components/underscore/underscore.js',
- 'components/backbone/backbone.js'];
- grunt.initConfig({
- concat: {
- js: {
- src: dependencies,
- dest: 'app/js/lib.js'
- }
- }
- });
- grunt.loadNpmTasks('grunt-contrib-concat');
- };
這里的grunt-contrib-concat就是grunt的一個插件，用于文件的合并操作，我們已經在前面的package.json中引入了。js是task name；src指定了合并的源文件地址；dest指定了合并的目標文件。這樣當我們運行grunt concat:js后，所有的依賴文件都會被合并為app/js/lib.js。這樣做的好處是我們可以控制每個依賴的引入順序，但是麻煩的是每次引入新的依賴都需要手動加入到dependencies數組中。這個暫時沒有更好的解決方案，因為不是所有的包都在自己的components.js中聲明了main文件，很多時候必須自己手動指定。
JavaScript文件編譯完成以后就是CSS文件，在現代的前端開發中，我們已經很少直接寫CSS文件了，一般都使用SASS或者LESS。grunt也提供了這種支持，這里我使用的是grunt-contrib-compass：
- module.exports = function(grunt) {
- var sasses = 'sass';
- grunt.initConfig({
- compass: {
- development: {
- options: {
- sassDir: sasses,
- cssDir: 'app/css'
- }
- }
- }
- });
- grunt.loadNpmTasks('grunt-contrib-compass');
- };
然后運行grunt compass:development就可以完成CSS文件的編譯了。
自動化測試
這里我使用的自動化測試工具是Jasmine，它grunt中同樣有一個插件：grunt-contrib-jasmine。下面我們來看看如何在Gruntfile.js中定義測試的task：
- module.exports = function(grunt) {
- var sources = 'app/js/**/*.js',
- specs = 'spec/**/*Spec.js';
- grunt.initConfig({
- jasmine: {
- test: {
- src: [sources],
- options: {
- specs: specs,
- helpers: ['spec/helper/**/*.js'],
- vendor: 'app/js/lib.js'
- }
- }
- }
- });
- grunt.loadNpmTasks('grunt-contrib-jasmine');
- };
配置完成以后就可以運行grunt jasmine:test來跑測試，但問題是每次寫完代碼都要手動執行一次非常麻煩，最好可以每次代碼有更改都自動跑一次，讓我們可以更快的得到反饋。grunt的watch插件就提供了這種支持：
- module.exports = function(grunt) {
- var sources = 'app/js/**/*.js',
- specs = 'spec/**/*Spec.js';
- grunt.initConfig({
- jasmine: {
- test: {
- src: [sources],
- options: {
- specs: specs,
- helpers: ['spec/helper/**/*.js'],
- vendor: 'app/js/lib.js'
- }
- }
- },
- watch: {
- test: {
- files: [sources, specs],
- tasks: ['jasmine:test']
- }
- }
- });
- grunt.loadNpmTasks('grunt-contrib-jasmine');
- grunt.loadNpmTasks('grunt-contrib-watch');
- };
files指定了需要監聽變動的文件；tasks指定了修改后自動觸發的task。現在只要我們運行grunt watch:test，那么有任何源文件、測試文件的改動，Jasmine測試都會自動運行了。有時候我們也希望測試的結果顯示在網頁上，便于我們做js的調試。那么可以將tasks:['jasmine:test']改為tasks: ['jasmine:test:build']，然后打開根目錄下的_SpecRunner.html文件，就可以在網頁中看到測試結果了，再加上一些Chrome的Livereload插件，就可以不用刷新實時的看到測試結果，效率非常之高。雖然grunt插件中也有livereload，但是與grunt-contrib-watch無法很好的集成，所以我沒有使用這種方式。
CI Pipeline
由于我的項目是host在github上，所以我選擇travis-ci作為我的CI服務器。要啟用travis-ci需要以下幾步：
- 在travis-ci中注冊一個賬號，獲取一個token；
- 在你的github項目的Settings–>Service Hooks中找到Travis，填入token并且啟用；
- 回到travis-ci，在Accounts–>Repositories中打開你的項目的service hook
- Push一個
.travis.yml到github，觸發第一次build。 - 修改
package.json的scripts項，指定運行測試的命令
下面我們來看看如何配置.travis.yml：
- language: node_js
- node_js:
- - "0.8"
- before_script:
- - npm install -g grunt-cli
由于我們的環境是基于Node.js搭建的，所以在language設置了nodejs；而**nodejs指定了Node.js的版 本；before_script**指定了在測試運行前需要執行的命令，由于我們的腳本都是基于grunt的，所以需要先安裝grunt的命令行包。
然后再修改package.json：
- {
- ⋯⋯
- "scripts": {
- "test": "grunt jasmine:test"
- }
- ⋯⋯
- }
將修改以后的package.jsonpush到github上，再次觸發一個新的build，你可以看到你之前錯誤的build已經綠了。
這里還有一個小提示：如何讓build狀態顯示在項目的readme中？很簡單，只需要在README.md中加入以下代碼就可以了：
- [](http://travis-ci.org/path/to/your_repository)
到這里基本的環境搭建就完成了，當然我們還可以使用grund的registerTask來定義一個任務序列，還可以加 入template的編譯⋯⋯這些都可以通過grunt來靈活設置。最重要的是現在別人拿到一個項目的代碼以后，可以通過一些命令來快速的搭建本地環境， 方便的進行測試和開發，而且沒有依賴與后端的開發環境，只要定義好接口，前端開發可以完全獨立開了。雖然這其中還有很多問題沒有解決，例如：
- 如何讓第三方依賴自申明main文件
package.json與components.json其實有些重復- Live Reload還需要Chrome插件才能完成
- ⋯⋯
這正是由于現在前端開發環境還沒有后端開發的那種標準化，也正是挑戰和機遇之所在！
原文鏈接：http://www.zation.me/2013/03/15/how-to-build-frontend-dev-env.html
