本文章旨在講解grunt入門,以及講解grunt最經常使用的幾個插件的使用。javascript
Grunt和全部grunt插件都是基於nodejs來運行的,若是你的電腦上沒有nodejs,就去安裝吧。安裝nodejs很是簡單,徹底傻瓜式、下一步下一步下一步、的安裝方式,這裏再也不贅述。去 https://nodejs.org/ 上,點擊頁面中那個綠色、大大的「install」按鈕便可。我這兒在百度雲盤存放一個,須要的點擊下載css
安裝了nodejs以後,能夠在你的控制檯中輸入「node -v」來查看nodejs的版本,也順便試驗nodejs是否安裝成功。
如圖所示:html
須要注意的是grunt依賴於nodejs的v0.8.0及以上版本。前端
注意,若是你的電腦不聯網,如下操做你都作不了,因此,首先保證電腦聯網。java
「CLI」被翻譯爲「命令行」。要想使用grunt,首先必須將grunt-cli
安裝到全局環境中,使用nodejs的「npm install…
」進行安裝。若是你不瞭解nodejs的npm如何安裝軟件,這裏就先不要問了,先照着我說的作。
打開控制檯(注意:windows系統下請使用管理員權限打開),輸入:node
注意,mac os 系統、部分linux系統中,在這句話的前面加上「sudo 」指令。
jquery
回車,命令行會出現一個轉動的小橫線,表示正在聯網加載。加載的時間看你網速的快慢,不過這個軟件比較小,通常加載時間不會很長,稍一下子,就加載完了。你會看到如下界面。linux
這時候要驗證一下grunt-cli是否安裝完成並生效,你只須要繼續在命令行中輸入「grunt」命令便可。若是生效,則會出現如下結果:git
Grunt是應用於實際項目的,因此咱們得有一個簡單的測試網站來演示grunt的安裝、使用。
首先,我在電腦的E盤下面建了一個「grunt_test」文件夾,裏面建了三個空文件夾、兩個空文檔,名稱以下圖。(注意 Gruntfile.js 文件的首字母大寫!)github
其餘的東西先不要管,先把package.json這個文件寫一些東西。記住,既然文件後綴名叫「json」,那麼文件中的格式確定是嚴格的json格式。
書歸正傳。Package.json的內容咱們寫成以下格式:
{ "name": "grunt_test", "version": "1.0.0", "devDependencies": { } }
很簡單,咱們把這個網站或系統的名稱、版本寫了一下。可是,不光是寫在這裏佔空的,之後會用到的,具體如何用,咱們下文會有介紹,先彆着急。
還有,最後一個「devDependencies」是什麼意思?字面意思解釋是「開發依賴項」,即咱們如今這個系統,將會依賴於哪些工具來開發。如今代碼一行都沒有寫,依賴於誰?誰也不依賴!因此,就先寫一個空對象。可是下文會慢慢把它填充起來。
另外,其實package.json中你能夠增長任何符合json格式的代碼,它生來自由,僅僅受json代碼格式的限制。
怎麼樣,看到這裏,是否是以爲下文頗有懸念,很想看下去呀?那就繼續!
接下來咱們會有一系列插件的安裝,他們的安裝過程和grunt同樣。可是他們的執行都是基於grunt的,所以才能把grunt叫作一個「構建工具」。Grunt沒有具體的做用,可是它能把有具體做用的一個一個插件組合起來,造成一個總體效應。
例如,你須要檢查js語法錯誤,而後再去壓縮js代碼。若是這兩步你都去手動操做,會耗費不少成本。Grunt就能讓你省去這些手動操做的成本。
書歸正傳。注意,這裏安裝grunt再也不是全局安裝了,須要你在控制檯進入到網站或系統的具體目錄下。這裏咱們進入 E:\grunt_test 目錄下。
而後輸入如下命令:
注意,先不要按回車,先不要執行,先看看下文的描述!
這裏須要解釋的是,「—save-dev」的意思是,在當前目錄安裝grunt的同時,順便把grunt保存爲這個目錄的開發依賴項。看到「開發依賴項」這一次,是否是以爲有些眼熟?上文在配置package.json時,其中的「devDependencies」中就會存儲開發依賴項。
具體保存爲開發依賴項是一個什麼效果?動手安裝一下就是了。首先,在運行安裝grunt的命令以前,package.json中的「devDependencies」對應的是空對象。
如今咱們來運行這行命令。你會看到幾條warning提示,不用管它。而後接下來就是加載狀態,一個旋轉的小橫線。稍等待一下子,會提示你安裝成功。以下圖:
如今你應該第一時間打開package.json去看看,那裏的「devDependencies」有什麼變化。我這裏的變化以下圖,看看你的是否是和個人同樣?
{ "name": "grunt_test", "version": "1.0.0", "devDependencies": { "grunt": "^0.4.5" } }
而後你再看看文檔目錄中的文件或者文件夾有什麼變化?我這裏多了一個「node_modules」文件夾,其中有一個「grunt」文件夾,再其中有若干文檔。這裏就是存儲grunt源文件的地方。
這是見證奇蹟的時刻,彆着急,奇蹟還沒完呢。而後你在控制檯運行「grunt」命令。若是你獲得一個warning提示,那說明grunt已經起做用了。以下圖:
通過以上三步,說明grunt已經在這個目錄下成功安裝。
那麼,爲什麼咱們在剛纔執行grunt時候會有Warning提示呢?根據提示,咱們得知的信息是:Task 「default」 not found ,如何搞定這個問題?——固然是繼續往下看啊。
顧名思義,Gruntfile.js 這個文件,確定是爲了grunt作某種配置的。按照grunt的規定,咱們首先把Gruntfile.js配置成以下格式。
//包裝函數 module.exports = function(grunt){ //任務配置,全部插件的配置信息 grunt.initConfig({ //獲取package.json的信息 pkg: grunt.file.readJSON('package.json') }); //告訴grunt當咱們在終端中輸入grunt時須要作些什麼(注意前後順序) grunt.registerTask('default',[]); };
在以上代碼中,咱們看到了剛纔運行grunt命令,warning提示中的「default」字眼。不妨咱們此時再運行一下grunt命令,看看會不會再次出現「warning」、「default」等字眼。
運行結果告訴咱們「Done, without errors」。那就繼續往下吧。
另外請注意Gruntfile.js中的一句話:
//獲取package.json的信息 pkg: grunt.file.readJSON('package.json')
這句話是在Gruntfile.js中獲取package.json中的內容。在上文配置package.json時咱們說過:package.json中的內容不光是用來佔位置的,還能夠在其餘地方獲取。這裏不是已經獲取了package.json內容了嗎?至於獲取瞭如何使用,下文會有介紹,仍是繼續往下看吧。
進入grunt官網的插件列表頁面 http://www.gruntjs.net/plugins ,咱們能看到grunt到目前位置的全部插件。
插件分爲兩類。第一類是grunt團隊貢獻的插件,這些插件的名字前面都帶有「contrib-」前綴,並且在插件列表中有星號標註。第二類是第三方提供的插件,不帶有這兩個特徵。
和jquery同樣,插件那麼多,確定不會所有用。grunt官網插件列表的前幾個插件中的前幾個插件,下載量最多,它們確定是你們都在用的插件。
我們能夠把前幾名插件的做用簡單描述一下,看看你在實際編碼過程當中是否須要?其實不用看就知道答案——確定須要——要否則怎麼會下載量那麼高呢?
Contrib-jshint——javascript語法錯誤檢查;
Contrib-watch——實時監控文件變化、調用相應的任務從新執行;
Contrib-clean——清空文件、文件夾;
Contrib-uglify——壓縮javascript代碼
Contrib-copy——複製文件、文件夾
Contrib-concat——合併多個文件的代碼到一個文件中
karma——前端自動化測試工具
以上這些插件,本文不會所有講到。可是隨着講解其中的一部分,我想你就能掌握使用grunt插件的方法。知道方法了,而後你就能夠參考官方文檔去使用你想要的插件。
grunt
集全世界web前端開發的智慧於一身,比你想一想的更增強大,它的插件庫能應對你在web前端開發遇到的任何事情。
還等什麼,繼續往下看。
Uglify
插件的功能就是壓縮javascript代碼。至於javascript代碼壓縮的必要和意義,這裏就不用在贅述了吧?幾乎每個javascript類庫或者框架,都有一個 **.min.js 壓縮版。
問一句,你平時作javascript開發,都用什麼工具來壓縮代碼?我想這個問題會有許多個答案。可是,使用grunt的uglify插件進行壓縮,效果絕對不輸於任何插件。
要安裝一個插件,你首先要進入這個插件在grunt官網的說明文檔頁面。咱們在grunt官網插件列表頁面,找到「contrib-uglify
」點擊進入。你要看這裏面的說明,而後根聽說明進行安裝。這裏咱們只講重點。
安裝uglify
插件的方式,和安裝grunt
是同樣的。還記得grunt是怎麼安裝的嗎?
npm install grunt-contrib-uglify --save-dev
這裏又出現了熟悉的「—save-dev」,具體的做用在上文安裝grunt時已經說過了,再也不贅述。運行這句命令。安裝完成以後,你會看到package.json中「devDependencies」節點的變化,以及「node_modules」文件夾裏的變化。這兩點都在安裝grunt時已經詳細說過。
如今還不能用,還須要在Gruntfile.js 作配置。
不過,先彆着急。咱們既然要使用uglify來壓縮javascript代碼,固然得建立一個js文件來作實驗。咱們在現有的「src」文件夾中新建一個「test.js」,並隨便寫一些代碼。顯然,咱們沒法經過雙手和鍵盤寫出壓縮後的代碼。
(function(window,undefined){ function add(a,b){ return a + b; } add(10,100); })(window);
測試文件創建好了。咱們接下來就要把這個js文件進行壓縮。
固然,要壓縮誰?往哪裏壓縮?這些都須要配置,在Gruntfile.js中配置。分爲三步:
第一步,在grunt.initConfig方法中配置 uglify 的配置參數。以下:
uglify的配置代碼:
//uglify插件的配置信息 uglify:{ options:{ banner:'/*! <%= pkg.name %> - v<%= pkg.version %> - <%= grunt.template.today("yyyy-mm-dd") %> */' }, build:{ src:'src/test.js', dest:'build/<%=pkg.name%><%pkg.version%>.min.js' } }
上圖中,對uglify的配置有兩項。
「options」中規定容許生成的壓縮文件帶banner,即在生成的壓縮文件第一行加一句話說明。注意,其中使用到了pkg獲取package.json的內容。
「build」中配置了源文件和目標文件。即規定了要壓縮誰?壓縮以後會生成誰?注意,咱們這裏將目標文件的文件名經過pkg的name和version來命名。
(PS:上文中說過的package.json的內容終於找到了他被應用的地方了。這樣的好處是:例如,對文件版本的管理,你只須要在package.json中修改便可,grunt會自動根據最新的版本號生成相應版本的文件。你不用手動去修改文件的文件名。)
最後,這裏只是對「options」和「build」的基本應用,還有許多中使用方式,能夠去官網查閱。
第二步,在 grunt.initConfig 方法以後,要讓grunt去加載這一個插件。光配置了,不加載上,如何用啊?
代碼以下:
grunt.loadNpmTasks('grunt-contrib-uglify');
第三步,在grunt命令執行時,要不要當即執行uglify插件?若是要,就寫上,不然不寫。我如今是須要的,因此我寫上。也有可能不須要,這種狀況誰知道呢?
代碼以下:
grunt.registerTask('default', ['uglify']);
以上說的這三步已經OK了,接下來咱們去試試。在控制檯中運行grunt命令,看獲得什麼結果。
控制檯將輸入以下信息:
再去看看,是否生成了一個壓縮後的js文件?
果真。根據package.json中的name和version生成了文件名。並且,壓縮後的代碼的banner也是符合Gruntfile.js中的配置要求的。
以上就是uglify插件的詳細安裝、配置說明。Javascript使用uglify
壓縮,css可以使用cssmin
插件壓縮。安裝、配置方法同樣的,再也不贅述。
若是你僅僅寫一個幾十行js代碼作一個小測試,語法錯誤的檢查大可沒必要。但我相信看這篇文章的朋友,確定不限於此,你可能天天都須要寫一大堆的js代碼來完成本身的工做。即便再牛、再仔細的人也會犯一些低級錯誤,可是jshint不會。所以,你最好的作法就是每時每刻都讓jshint來幫助你檢查剛剛寫過的js代碼,有錯誤當即發現當即處理。這樣一來,大家就不必每隔幾天都相聚在會議室進行人工代碼走查了。及時代碼走查,你也不必刻意的關注語法錯誤。
還有一些js初級入門的朋友,或者已經有多年js經驗,卻「不思進取」的朋友。你到如今可能都不知道一些js語法歸法。例如:你到如今可能都不知道「==」和「===」到底有什麼區別,你到如今都不知道在語句塊內定義變量的壞處,還有更多更多你不知道的。怎麼辦?讓jshint來幫助你。
接下來介紹jshint的安裝和配置。
插件的安裝和安裝grunt、uglify沒有任何差異,這裏再也不贅述了。直接執行下面的命令
npm install grunt-contrib-jshint --save-dev
配置jshint和配置uglify同樣。在配置uglify時候咱們講到了三個步驟,這裏也是三個步驟。
第一步,在grunt.initConfig方法中配置jshint。
代碼以下:
//jshint的插件配置信息 jshint:{ build:['Gruntfile.js','src/*.js'], options:{ jshintrc:'.jshintrc' //檢測JS代碼錯誤要根據此文件的設置規範進行檢測,能夠本身修改規則 } }
和uglify的配置同樣,分爲「options」和「build」兩個部分。「build」中描述了jshint要檢查哪些js文檔的語法。「options」中描述了要經過怎麼的規則檢查語法,這些規則的描述文件就保存在網站根目錄下的一個叫作「.jshintrc」的文件中。所以咱們在網站的根目錄下面添加上這個文檔,而且填寫上文件內容。
代碼以下:
{ "curly": true, "eqeqeq": true, "immed": true, "newcap": true, "noarg": true, "undef": true, "boss": false, "eqnull": true, "node": true, "expr":true, "noempty":true, "regexp":true, "browser":true, "devel":true }
.jshintrc文件中代碼的格式也要遵照嚴格的json語法,不然無效。那裏面這些配置是什麼意思呢?想詳細瞭解能夠去百度搜索「jshint 配置」關鍵字,你就能知道答案。這裏因爲篇幅太多,不過多介紹。總之吧,這個.jshint是我經常使用的配置。
第二步,加載插件。和uglify的加載方法同樣。注意,這裏沒有前後順序。
代碼以下:
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-jshint');
第三步,配置grunt命令啓動時,要執行的任務,這裏注意前後順序。你是但願先檢查語法呢?仍是先合併呢?——聰明人應該都知道先檢查語法比較好,由於語法對,合併了有什麼意義?
代碼以下:
grunt.registerTask('default', ['jshint','uglify']);
以上三步配置完了以後,咱們能夠測試一下這個jshint到底怎麼用。這裏我故意將當前建立的test.js文件寫一個語法錯誤。
而後咱們執行「grunt」命令,看jshint能給咱們識別出來這兩個錯誤嗎?結果以下:
看到沒有,jshint很清除的識別出了這兩個錯誤。並且注意到沒有,jshint錯誤以後呢,其後面的uglify就沒有再繼續執行。這正式咱們想要的結果。
咱們修改完這些錯誤,在此執行grunt命令,結果沒有提示錯誤,並且jshint和uglify都順利執行了。
檢查css文件的語法錯誤要使用csslint插件,其安裝配置方法和jshint幾乎如出一轍。只不過csslint依賴於一個叫作「.csslintrc
」的文件做爲語法檢驗的規則,個人「.csslintrc
」文件以下。其餘內容咱們就不在此贅述了。
代碼以下:
{ "adjoining-classes": false, "box-sizing": false, "box-model": false, "compatible-vendor-prefixes": false, "floats": false, "font-sizes": false, "gradients": false, "important": false, "known-properties": false, "outline-none": false, "qualified-headings": false, "regex-selectors": false, "shorthand": false, "text-indent": false, "unique-headings": false, "universal-selector": false, "unqualified-attributes": false }
你能夠一直有一個疑問,上面將的插件中,每次執行插件功能,都得執行一遍「grunt」命令,這樣的操做很是繁瑣,說好的「自動化」呢?彆着急,接下來就解決這個問題——經過watch插件解決這個問題。
首先安裝watch插件,若是安裝再也不贅述了。接下來要配置watch插件,配置分爲三個步驟,再也不詳細描述了,只貼圖說明。
第一步。配置watch將監控哪些文件的變化,以及這些文件一旦變化,要當即執行哪些插件功能。以下圖,watch將監控src文件夾下全部js文件和css文件的變化,一旦變化,則當即執行jshint
和uglify
兩個插件功能。
第二步,直接帖代碼:
grunt.loadNpmTasks('grunt-contrib-watch');
第三步,直接帖代碼:
grunt.registerTask('default', ['jshint','uglify','watch']);
這三步執行完了,即watch插件配置完成。運行grunt命令,控制檯提示watch已經開始監聽。此時要想中止,按ctrl + c便可。
既然在監聽,咱們試一試看監聽有沒有效。咱們將 test.js 代碼中去掉一個分號,看它可否自動檢查出來這個錯誤。
結果顯示,watch檢查到了test.js文件的變化,並且經過執行jshint提示了語法錯誤。更重要的是,它如今還在監聽、並未中止。說明它正在等着你去修改錯誤,從新監聽檢查。那咱們就不要辜負它了,再把語法錯誤修復了。看它會如何處理。
它又檢測到了文件變化,此次語法沒有錯誤,它很順利的執行了jshint和uglify,執行完畢以後從新進行監聽。多聽話的工具!
好了,已經回答了大家的問題——自動化。
上文中描述各個插件的配置時,都是用了「build」這一名稱做爲一個配置項。
那麼這裏是否是必須用「build」這一個名字?答案很明顯,固然不是。我以前之因此沒直接說,是由於我要先把插件的安裝和配置講明白,不變一次傳輸太多知識,如今一併和你們說了。
這裏能夠用任何字符串代替「build」(但要符合js語法規則)。甚至,你能夠把「build」指向的內容分開來寫。這樣對多人協同開發很友好。好的設計就是這樣:讓用戶盡情發揮他們的自由來幹事,而不是去限制他們。
如上圖,我對jshint的配置作了修改,你們能夠去本身修改,而後執行grunt命令試試。命令行會有「test1」、「test2」的字眼。
如圖所示:
請各位看官繼續跟隨我思考問題,學而不思則罔。
到如今爲止,我剛剛安裝了3個插件,「node_modules」文件夾所佔據的空間就有18MB了。你們猜一猜,我在上傳代碼到開發庫的時候,會不會把「node_modules」中的內容也上傳呢?既然我這麼問了,答案確定是不上傳。
問題又來了,我若是做爲開發環境的搭建者,我不把「node_modules」上傳,其餘一塊兒開發的人,怎麼獲得這些grunt插件和工具呢?有人回答讓他們本身去手動一個一個安裝——首先這是一個笨方法,其次若是我當年安裝的舊版本,而他們如今本身安裝的多是新版本。新舊有可能不兼容啊。
該怎麼辦?
其實答案很簡單——我上傳源碼時候,確定會把package.json上傳上去,而package.json中的「devDependencies」就記錄了這個系統的開發依賴項,而後我經過nodejs的npm便可批量安裝。
作一個試驗。我在E盤下面新建一個目錄「grunt_test_1」,而後把「grunt_test」中的package.json拷過去。在打開命令行跳轉到「grunt_test_1」,執行「npm install」命令,看看獲得什麼結果。
此時按回車執行命令,結果在「grunt_test_1」生成了「node_modules」文件夾,裏面安裝好了package.json中「devDependencies」配置的插件。並且,版本都是一直的。
使用grunt來搭建web前端開發環境時候,文檔目錄和以前可能就不同了。由於你手動寫的代碼文件,絕對不是你最終輸出的文件。這些還須要通過grunt各類插件的檢驗、合併、壓縮才能最終輸出給用戶。
下面截圖看一個文檔結構例子:
上圖中,「src」文件夾裏面存儲的是原始的代碼文件,「dist」文件夾裏面存儲的是最終生成的代碼文件,「demo」裏面存儲的是一些測試頁面。
固然了,各個系統的文件組織形式不同,可是我建議你們仍是按照這麼一個思想去組織文檔結構。你們也能夠去github上參考一下jquery、bootstrap這些著名開源項目的文檔結構。看看jquery輸出的雖然是簡單的一個js文件,可是它的開發環境是多麼的複雜。
參考地址:grunt插件官網:http://www.gruntjs.net/plugins30分鐘學會使用grunt打包前端代碼:http://www.cnblogs.com/yexiaochai/p/3603389.htmlhttp://blog.csdn.net/wangfupeng1988/article/details/46418203/http://www.xgllseo.com/?p=4287