[[136136]]

jQuery在使用grunt，bootstrap在使用grunt，百度UEditor在使用grunt，你沒有理由不學、不用！

1. 前言

　　各位web前端開發人員，如果你現在還不知道grunt或者聽說過、但是不會熟練使用grunt，那你就真的真的真的out了（三個“真的”重復，表 示重點）。至于grunt的作用，這里不詳細說了，總之你如果做web前端開發，你一定要用grunt。還有一點，它完全免費，沒有盜版。既強大又免費的 東西，為何不用？

　　當然了，你如果你能找到更好的替代grunt的其他工具也是可以的，例如gulp。Gulp未來有可能替代grunt，但是現在來說市場占有率還是不如grunt。而這種工具咱們是現在就需要用的，所有不要再猶豫了，拿來主義，先用grunt，即學即用。

　　本文章旨在講解grunt入門，以及講解grunt最常用的幾個插件的使用。篇幅可能會比較長，大家耐心看。本文例證詳細、清晰的講解每一個知識點。 但是——如果你看完本文還是不會，我還有最后一個大招。不過你可能需要付出一頓飯錢 + 一包煙錢的代價——去看看我錄制的視頻教程《用grunt搭建自動化的web前端開發環境》（教程中有源碼下載） ，保證你看完就會用。

　　（PS：碰巧，本文基于windows環境寫的，而視頻教程是基于mac os錄制的，兩者兼備了）

　　廢話不多少，視頻教程你也先別看，錢別著急花。先挑戰一下自己的理解能力，看下文講述是否清晰、是否能看懂。

2. 安裝nodejs

　　Grunt和所有grunt插件都是基于nodejs來運行的，如果你的電腦上沒有nodejs，就去安裝吧。安裝nodejs非常簡單，完全傻瓜式、下一步下一步下一步、的安裝方式，這里不再贅述。去 https://nodejs.org/ 上，點擊頁面中那個綠色、大大的“install”按鈕即可。

　　安裝了nodejs之后，可以在你的控制臺中輸入“node -v”來查看nodejs的版本，也順便試驗nodejs是否安裝成功。

　　

　　注意兩點。第一，grunt依賴于nodejs的v0.8.0及以上版本；第二，奇數版本號的版本被認為是不穩定的開發版，不過從官網上下載下來的應該都是偶數的穩定版。

3. 安裝grunt-CLI

　　注意，如果你的電腦不聯網，以下操作你都做不了，所以，首先保證電腦聯網。

　　“CLI”被翻譯為“命令行”。要想使用grunt，首先必須將grunt-cli安裝到全局環境中，使用nodejs的“npm install…”進行安裝。如果你不了解nodejs的npm如何安裝軟件，這里就先不要問了，先照著我說的做。

　　打開控制臺（注意：windows系統下請使用管理員權限打開），輸入：

　　

　　注意，mac os 系統、部分linux系統中，在這句話的前面加上“sudo ”指令。

　　回車，命令行會出現一個轉動的小橫線，表示正在聯網加載。加載的時間看你網速的快慢，不過這個軟件比較小，一般加載時間不會很長，稍一會兒，就加載完了。你會看到以下界面。

　　

　　這時候要驗證一下grunt-cli是否安裝完成并生效，你只需要繼續在命令行中輸入“grunt”命令即可。如果生效，則會出現以下結果：

　　

　　你不要管這些結果是什么意思，總之出現這些提示，證明你的grunt-cli安裝成功了。

#p#

4. 創建一個簡單的網站

　　Grunt是應用于實際項目的，所以我們得有一個簡單的測試網站來演示grunt的安裝、使用。

　　首先，我在電腦的D盤下面建了一個“grunt_test”文件夾，里面建了三個空文件夾、兩個空文檔，名稱如下圖。（注意 Gruntfile.js 文件的首字母大寫！）

　　

　　其他的東西先不要管，先把package.json這個文件寫一些東西。記住，既然文件后綴名叫“json”，那么文件中的格式肯定是嚴格的json格式。什么，不熟悉json？作為一個web前端程序猿，json是必備課。有一個教程《json2.js源碼解讀》能讓你徹底了解json。

　　書歸正傳。Package.json的內容我們寫成如下格式：

　　

　　很簡單，我們把這個網站或系統的名稱、版本寫了一下。但是，不光是寫在這里占空的，以后會用到的，具體如何用，我們下文會有介紹，先別著急。

還有，最后一個“devDependencies”是什么意思？字面意思解釋是“開發依賴項”，即我們現在這個系統，將會依賴于哪些工具來開發?，F在代碼一行都沒有寫，依賴于誰？誰也不依賴！所以，就先寫一個空對象。但是下文會慢慢把它填充起來。

另外，其實package.json中你可以增加任何符合json格式的代碼，它生來自由，僅僅受json代碼格式的限制。

　　怎么樣，看到這里，是不是覺得下文很有懸念，很想看下去呀？那就繼續！

5. 安裝grunt

　　主角總是姍姍來遲。《三國演義》在開篇三分一之后才請出來諸葛亮，《水滸傳》在第十八回才請出了宋江。而我們本文的主角，也出來的不早。

　　接下來我們會有一系列插件的安裝，他們的安裝過程和grunt一樣。但是他們的執行都是基于grunt的，因此才能把grunt叫做一個“構建工具”。Grunt沒有具體的作用，但是它能把有具體作用的一個一個插件組合起來，形成一個整體效應。

　　例如，你需要檢查js語法錯誤，然后再去壓縮js代碼。如果這兩步你都去手動操作，會耗費很多成本。Grunt就能讓你省去這些手動操作的成本。

　　書歸正傳。注意，這里安裝grunt不再是全局安裝了，需要你在控制臺進入到網站或系統的具體目錄下。這里我們進入 D:\grunt_test 目錄下。然后輸入以下命令。

　　

　　注意，先不要按回車，先不要執行，先看看下文的描述！

　　這里需要解釋的是，“—save-dev”的意思是，在當前目錄安裝grunt的同時，順便把grunt保存為這個目錄的開發依賴項。看到“開發依賴項”這一次，是不是覺得有些眼熟？上文在配置package.json時，其中的“devDependencies”中就會存儲開發依賴項。

　　具體保存為開發依賴項是一個什么效果？動手安裝一下就是了。首先，在運行安裝grunt的命令之前，package.json中的“devDependencies”對應的是空對象。

現在我們來運行這行命令。你會看到幾條warning提示，不用管它。然后接下來就是加載狀態，一個旋轉的小橫線。稍等待一會兒，會提示你安裝成功。如下圖：

　　

　　現在你應該第一時間打開package.json去看看，那里的“devDependencies”有什么變化。我這里的變化如下圖，看看你的是不是和我的一樣？

　　

　　然后你再看看文檔目錄中的文件或者文件夾有什么變化？我這里多了一個“node_modules”文件夾，其中有一個“grunt”文件夾，再其中有若干文檔。這里就是存儲grunt源文件的地方。

　　

　　這是見證奇跡的時刻，別著急，奇跡還沒完呢。然后你在控制臺運行“grunt”命令。如果你得到一個warning提示，那說明grunt已經起作用了。如下圖：

　　

　　經過以上三步，說明grunt已經在這個目錄下成功安裝。

　　那么，為何我們在剛才執行grunt時候會有Warning提示呢？根據提示，我們得知的信息是：Task “default” not found ，如何搞定這個問題？——當然是繼續往下看啊。

6. 配置Gruntfile.js

　　顧名思義，Gruntfile.js 這個文件，肯定是為了grunt做某種配置的。按照grunt的規定，我們首先把Gruntfile.js配置成如下格式。

　　

　　在以上代碼中，我們看到了剛才運行grunt命令，warning提示中的“default”字眼。不妨我們此時再運行一下grunt命令，看看會不會再次出現“warning”、“default”等字眼。

　　

　　運行結果告訴我們“Done, without errors”。那就繼續往下吧。

　　另外請注意Gruntfile.js中的一句話：

　　

　　這句話是在Gruntfile.js中獲取package.json中的內容。在上文配置package.json時我們說 過：package.json中的內容不光是用來占位置的，還可以在其他地方獲取。這里不是已經獲取了package.json內容了嗎？至于獲取了如何 使用，下文會有介紹，還是繼續往下看吧。

#p#

7. Grunt插件介紹

　　進入grunt官網的插件列表頁面 http://www.gruntjs.net/plugins ，我們能看到grunt到目前位置的所有插件。現在里面有4560個插件，這個數量每天都在增加。而且，這些既然出現在官網，肯定是經過審核的。

　　插件分為兩類。第一類是grunt團隊貢獻的插件，這些插件的名字前面都帶有“contrib-”前綴，而且在插件列表中有星號標注。第二類是第三方提供的插件，不帶有這兩個特征。

　　和jquery一樣，插件那么多，肯定不會全部用。grunt官網插件列表的前幾個插件中的前幾個插件，下載量最多，它們肯定是大家都在用的插件。第一名jshint插件最近30天下載量將近89萬次，這是多么驚人的下載量！

　　 咱們可以把前幾名插件的作用簡單描述一下，看看你在實際編碼過程中是否需要？其實不用看就知道答案——肯定需要——要不然怎么會下載量那么高呢？

• Contrib-jshint——javascript語法錯誤檢查；

• Contrib-watch——實時監控文件變化、調用相應的任務重新執行；

• Contrib-clean——清空文件、文件夾；

• Contrib-uglify——壓縮javascript代碼

• Contrib-copy——復制文件、文件夾

• Contrib-concat——合并多個文件的代碼到一個文件中

• karma——前端自動化測試工具

　　以上這些插件，本文不會全部講到。但是隨著講解其中的一部分，我想你就能掌握使用grunt插件的方法。知道方法了，然后你就可以參考官方文檔去使用你想要的插件。

　　grunt集全世界web前端開發的智慧于一身，比你想想的更加強大，它的插件庫能應對你在web前端開發遇到的任何事情。

　　還等什么，繼續往下看。

8. 使用uglify插件（壓縮javascript代碼）

　　Uglify插件的功能就是壓縮javascript代碼。至于javascript代碼壓縮的必要和意義，這里就不用在贅述了吧？幾乎每一個javascript類庫或者框架，都有一個 **.min.js 壓縮版。

　　問一句，你平時做javascript開發，都用什么工具來壓縮代碼？我想這個問題會有許多個答案。但是，使用grunt的uglify插件進行壓縮，效果絕對不輸于任何插件。

　　要安裝一個插件，你首先要進入這個插件在grunt官網的說明文檔頁面。我們在grunt官網插件列表頁面，找到“contrib-uglify”點擊進入。你要看這里面的說明，然后根據說明進行安裝。這里我們只講重點。

　　安裝uglify插件的方式，和安裝grunt是一樣的。還記得grunt是怎么安裝的嗎？

　　

　　這里又出現了熟悉的“—save-dev”，具體的作用在上文安裝grunt時已經說過了，不再贅述。運行這句命令。安裝完成之后，你會看到 package.json中“devDependencies”節點的變化，以及“node_modules”文件夾里的變化。這兩點都在安裝grunt 時已經詳細說過。

　　現在還不能用，還需要在Gruntfile.js 做配置。

　　不過，先別著急。我們既然要使用uglify來壓縮javascript代碼，當然得創建一個js文件來做實驗。我們在現有的“src”文件夾中新建一個“test.js”，并隨便寫一些代碼。顯然，我們無法通過雙手和鍵盤寫出壓縮后的代碼。

　　

　　測試文件建立好了。我們接下來就要把這個js文件進行壓縮。

　　當然，要壓縮誰？往哪里壓縮？這些都需要配置，在Gruntfile.js中配置。分為三步：

　　第一步，在grunt.initConfig方法中配置 uglify 的配置參數。如下圖：

　　

　　上圖中，對uglify的配置有兩項。

　　“options”中規定允許生成的壓縮文件帶banner，即在生成的壓縮文件第一行加一句話說明。注意，其中使用到了pkg獲取package.json的內容。

　　“build”中配置了源文件和目標文件。即規定了要壓縮誰？壓縮之后會生成誰？注意，我們這里將目標文件的文件名通過pkg的name和version來命名。

　　（PS：上文中說過的package.json的內容終于找到了他被應用的地方了。這樣的好處是：例如，對文件版本的管理，你只需要在package.json中修改即可，grunt會自動根據最新的版本號生成相應版本的文件。你不用手動去修改文件的文件名。）

　　最后，這里只是對“options”和“build”的基本應用，還有許多中使用方式，可以去官網查閱。

　　第二步，在 grunt.initConfig 方法之后，要讓grunt去加載這一個插件。光配置了，不加載上，如何用??？

　　

　　第三步，在grunt命令執行時，要不要立即執行uglify插件？如果要，就寫上，否則不寫。我現在是需要的，所以我寫上。也有可能不需要，這種情況誰知道呢？

　　

　　以上說的這三步已經OK了，接下來我們去試試。在控制臺中運行grunt命令，看得到什么結果。

　　控制臺將輸入如下信息：

　　

　　再去看看，是否生成了一個壓縮后的js文件？

　　

　　果然。根據package.json中的name和version生成了文件名。而且，壓縮后的代碼的banner也是符合Gruntfile.js中的配置要求的。

　　 以上就是uglify插件的詳細安裝、配置說明。Javascript使用uglify壓縮，css可使用cssmin插件壓縮。安裝、配置方法一樣的，不再贅述。

#p#

9. 使用jshint插件（檢查javascript語法錯誤）

　　如果你僅僅寫一個幾十行js代碼做一個小測試，語法錯誤的檢查大可不必。但我相信看這篇文章的朋友，肯定不限于此，你可能每天都需要寫一大堆的js代 碼來完成自己的工作。即使再牛、再仔細的人也會犯一些低級錯誤，但是jshint不會。因此，你最好的做法就是每時每刻都讓jshint來幫助你檢查剛剛 寫過的js代碼，有錯誤立即發現立即處理。這樣一來，你們就沒必要每隔幾天都相聚在會議室進行人工代碼走查了。及時代碼走查，你也沒必要刻意的關注語法錯 誤。

　　還有一些js初級入門的朋友，或者已經有多年js經驗，卻“不思進取”的朋友。你到現在可能都不知道一些js語法歸法。例如：你到現在可能都不知道 “==”和“===”到底有什么區別，你到現在都不知道在語句塊內定義變量的壞處，還有更多更多你不知道的。怎么辦？讓jshint來幫助你。

　　接下來介紹jshint的安裝和配置。

　　插件的安裝和安裝grunt、uglify沒有任何差別，這里不再贅述了。直接執行下面的命令

　　

　　配置jshint和配置uglify一樣。在配置uglify時候我們講到了三個步驟，這里也是三個步驟。

　　第一步，在grunt.initConfig方法中配置jshint。

　　

　　和uglify的配置一樣，分為“options”和“build”兩個部分。“build”中描述了jshint要檢查哪些js文檔的語法。 “options”中描述了要通過怎么的規則檢查語法，這些規則的描述文件就保存在網站根目錄下的一個叫做“.jshintrc”的文件中。因此我們在網 站的根目錄下面添加上這個文檔，并且填寫上文件內容。

　　

　　.jshintrc文件中代碼的格式也要遵守嚴格的json語法，否則無效。那里面這些配置是什么意思呢？想詳細了解可以去百度搜索“jshint 配置”關鍵字，你就能知道答案。這里由于篇幅太多，不過多介紹?？傊?，這個.jshint是我常用的配置。

　　第二步，加載插件。和uglify的加載方法一樣。注意，這里沒有先后順序。

　　

　　第三步，配置grunt命令啟動時，要執行的任務，這里注意先后順序。你是希望先檢查語法呢？還是先合并呢？——聰明人應該都知道先檢查語法比較好，因為語法對，合并了有什么意義？

　　

　　以上三步配置完了之后，我們可以測試一下這個jshint到底怎么用。這里我故意將當前創建的test.js文件寫一個語法錯誤。

　　

　　然后我們執行“grunt”命令，看jshint能給我們識別出來這兩個錯誤嗎？結果如下：

　　

　　看到沒有，jshint很清除的識別出了這兩個錯誤。而且注意到沒有，jshint錯誤之后呢，其后面的uglify就沒有再繼續執行。這正式我們想要的結果。

　　我們修改完這些錯誤，在此執行grunt命令，結果沒有提示錯誤，而且jshint和uglify都順利執行了。

      

10. 使用csslint插件（檢查css語法錯誤）

　　檢查css文件的語法錯誤要使用csslint插件，其安裝配置方法和jshint幾乎一模一樣。只不過csslint依賴于一個叫做“.csslintrc”的文件作為語法檢驗的規則，我的“.csslintrc”文件如下。其他內容我們就不在此贅述了。

　　

#p#

11. 使用watch插件（真正實現自動化）

　　你可以一直有一個疑問，上面將的插件中，每次執行插件功能，都得執行一遍“grunt”命令，這樣的操作非常繁瑣，說好的“自動化”呢？別著急，接下來就解決這個問題——通過watch插件解決這個問題。

　　首先安裝watch插件，如果安裝不再贅述了。接下來要配置watch插件，配置分為三個步驟，不再詳細描述了，只貼圖說明。

　　第一步。配置watch將監控哪些文件的變化，以及這些文件一旦變化，要立即執行哪些插件功能。如下圖，watch將監控src文件夾下所有js文件和css文件的變化，一旦變化，則立即執行jshint和uglify兩個插件功能。

　　

　　第二步，直接貼圖

　　

　　第三步，直接貼圖

　　

　　這三步執行完了，即watch插件配置完成。運行grunt命令，控制臺提示watch已經開始監聽。此時要想停止，按ctrl + c即可。

　　

　　既然在監聽，我們試一試看監聽有沒有效。我們將 test.js 代碼中去掉一個分號，看它能否自動檢查出來這個錯誤。

　　

　　結果顯示，watch檢查到了test.js文件的變化，而且通過執行jshint提示了語法錯誤。更重要的是，它現在還在監聽、并未停止。說明它正在等著你去修改錯誤，重新監聽檢查。那我們就不要辜負它了，再把語法錯誤修復了?？此鼤绾翁幚怼?/p>

　　

　　它又檢測到了文件變化，這次語法沒有錯誤，它很順利的執行了jshint和uglify，執行完畢之后重新進行監聽。多聽話的工具！

　　好了，已經回答了你們的問題——自動化。

12. 上文中所謂的“build”

　　上文中描述各個插件的配置時，都是用了“build”這一名稱作為一個配置項。

　　

　　那么這里是不是必須用“build”這一個名字？答案很明顯，當然不是。我之前之所以沒直接說，是因為我要先把插件的安裝和配置講明白，不變一次傳輸太多知識，現在一并和大家說了。

　　這里可以用任何字符串代替“build”（但要符合js語法規則）。甚至，你可以把“build”指向的內容分開來寫。這樣對多人協同開發很友好。好的設計就是這樣：讓用戶盡情發揮他們的自由來干事，而不是去限制他們。

　　

　　如上圖，我對jshint的配置做了修改，大家可以去自己修改，然后執行grunt命令試試。命令行會有“test1”、“test2”的字眼。

#p#

13. 批量安裝插件

　　請各位看官繼續跟隨我思考問題，學而不思則罔。

　　到現在為止，我剛剛安裝了3個插件，“node_modules”文件夾所占據的空間就有18MB了。大家猜一猜，我在上傳代碼到開發庫的時候，會不會把“node_modules”中的內容也上傳呢？既然我這么問了，答案肯定是不上傳。

　　問題又來了，我如果作為開發環境的搭建者，我不把“node_modules”上傳，其他一起開發的人，怎么得到這些grunt插件和工具呢？有人回 答讓他們自己去手動一個一個安裝——首先這是一個笨方法，其次如果我當年安裝的舊版本，而他們現在自己安裝的可能是新版本。新舊有可能不兼容啊。

　　該怎么辦？

　　其實答案很簡單——我上傳源碼時候，肯定會把package.json上傳上去，而package.json中的“devDependencies”就記錄了這個系統的開發依賴項，然后我通過nodejs的npm即可批量安裝。

　　做一個試驗。我在D盤下面新建一個目錄“grunt_test_1”，然后把“grunt_test”中的package.json拷過去。在打開命令行跳轉到“grunt_test_1”，執行“npm install”命令，看看得到什么結果。

　　

　　此時按回車執行命令，結果在“grunt_test_1”生成了“node_modules”文件夾，里面安裝好了package.json中“devDependencies”配置的插件。而且，版本都是一直的。

神奇吧！

　　

14. 系統文件結構

　　使用grunt來搭建web前端開發環境時候，文檔目錄和之前可能就不一樣了。因為你手動寫的代碼文件，絕對不是你最終輸出的文件。這些還需要經過grunt各種插件的檢驗、合并、壓縮才能最終輸出給用戶。

　　這里我拿自己的開源項目wangEditor的文檔結構舉例子。

　　

　　上圖中，“src”文件夾里面存儲的是原始的代碼文件，“dist”文件夾里面存儲的是最終生成的代碼文件，“demo”里面存儲的是一些測試頁面。

　　當然了，各個系統的文件組織形式不一樣，但是我建議大家還是按照這么一個思想去組織文檔結構。大家也可以去github上參考一下jquery、 bootstrap這些著名開源項目的文檔結構?？纯磈query輸出的雖然是簡單的一個js文件，但是它的開發環境是多么的復雜。

　　做好前端，不容易。

15. 完結

　　這篇文章我使用word寫的，然后粘貼到博客園中發布的。到現在為止，我寫了一共有20頁、6700多字，全部手寫、手動截圖。寫博客寫到這個份上，我也算是拼了！

　　如果你看完這篇文章還不會grunt，或者你懶得看文章、嫌累，我建議你去看看我錄制的《使用grunt搭建全自動web前端開發環境》這個視頻教程，視頻里講的肯定詳細的多了，而且可以下載源碼。

　　最后，大家如果覺得本文對你有幫助，就點個贊吧！