1. 程式人生 > >Grunt搭建自動化web前端開發環境--完整流程

Grunt搭建自動化web前端開發環境--完整流程

成本 鏈接地址 sta 一行 手動 css 變化 關鍵字 也會

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

1、 前言

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

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

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安裝成功了。

4.、創建一個簡單的網站

  npm init 創建package.json文件

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

  首先,我在電腦的D盤下面建了一個“grunt_test”文件夾,裏面建了三個空文件夾、兩個空文檔,名稱如下圖。(註意 Gruntfile.js 文件的首字母大寫!)

技術分享圖片

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

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

技術分享圖片

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

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

另外,其實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內容了嗎?至於獲取了如何使用,下文會有介紹,還是繼續往下看吧。

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插件壓縮。安裝、配置方法一樣的,不再贅述。

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”文件如下。其他內容我們就不在此贅述了。

技術分享圖片

11.、使用watch插件(真正實現自動化)

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

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

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

技術分享圖片

 第二步,直接貼圖

技術分享圖片

 第三步,直接貼圖

技術分享圖片

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

技術分享圖片

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

技術分享圖片

結果顯示,watch檢查到了test.js文件的變化,而且通過執行jshint提示了語法錯誤。更重要的是,它現在還在監聽、並未停止。說明它正在等著你去修改錯誤,重新監聽檢查。那我們就不要辜負它了,再把語法錯誤修復了。看它會如何處理。

技術分享圖片

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

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

12、上文中所謂的“build”

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

技術分享圖片

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

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

技術分享圖片

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

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這些著名開源項目的文檔結構。看看jquery輸出的雖然是簡單的一個js文件,但是它的開發環境是多麽的復雜。

  做好前端,不容易。

鏈接地址:http://blog.csdn.net/qq_34099161/article/details/53305449

my gruntfile.js

技術分享圖片

//定義一個模塊,並導出一個函數。 module.exports = grunt => { //初始化grunt配置 grunt.initConfig({ //定義一個動作:concat的作用是多個文件合並成一個文件。 concat:{ options:{ banner:"/*智遊教育*/\n" },//動作的選項,不是所有的任務都有選項。 dist:{//動作涉及的文件 src:[‘js/control.js‘, ‘js/dot.js‘, ‘js/second.js‘,‘js/minute.js‘,‘js/hour.js‘,‘js/diamond.js‘,‘js/clock.js‘],//要合並的文件 dest:‘js/myclock.js‘//合並後的文件名。 } }, uglify:{//壓縮js的動作 my_torget:{//動作目標 files:{//涉及的文件 ‘js/myclock.min.js‘:[‘js/myclock.js‘] //壓縮後生成的文件:需要壓縮的文件列表 } } } }) grunt.loadNpmTasks(‘grunt-contrib-concat‘) grunt.loadNpmTasks(‘grunt-contrib-uglify‘)//加載grunt插件模塊包。 grunt.registerTask(‘default‘,[‘concat‘, ‘uglify‘])//註冊任務,註冊後可以使用名字執行已註冊的任務,第一個參數:任務名字,第二個參數:具體要執行的動作,可以是多個動作按順序執行(數組) }

Grunt搭建自動化web前端開發環境--完整流程