腳手架vue-cli系列二：vue-cli的工程模板與構建工具

上篇文章咱們提到了vue-cli的工程模板。這裏咱們來詳細的進行介紹。

vue-cli提供的腳手架只是一個最基礎的，也能夠說是Vue團隊認爲的工程結構的一種最佳實踐。對於初學者或者之前曾從事AngularJS/React開發的用戶來講，可能對開發環境有自已習慣性用法和熟悉的工具，但我建議用Vue來開發的話仍是先按照官方推薦的來作，待咱們掌握了Vue官方推薦的環境配置後再按照實際狀況進行相應的調整，這樣會少走一些彎路，節省很多時間。

咱們下面要討論的工程結構都是圍繞webpack-simple與webpack展開的，browserify也只是在這兩個模板的基礎上移植的一個版本，因此就不過多地贅述。

webpack和webpack-simple這兩個模板從文件結構上看幾乎是一致的，只是一個是簡化版，另外一個是徹底版。其實否則，webpack-simple是基於Webpack@2.1.0-beta.25進行配置的版本，而webpack模板則是基於Webpack ^1.3.2配置的。這兩個版本暫時是互相不兼容的，並且使用的依賴包的版本也不同，因此不要將webpack模板建立的項目文件結構複製到webpack-simple中進行直接的取代升級，而是須要將node_modules內安裝的全部的依賴包刪除，而後從新安裝纔有可能遷移成功，這一點是須要注意的。

1.webpack-simple模板

如下爲webpack-simple模板構建的項目的工程目錄結構：

    ├── README.md
    ├── index.html
    ├── package.json
    ├── src
    │    ├── App.vue
    │    ├── assets
    │    │    └── logo.png
    │    └── main.js
    └── webpack.config.js

webpack-simple只配置了Babel和Vue的編譯器，其餘的一無全部。這個模板值得一提的就是src目錄，全部的Vue代碼源程序都放置在這個目錄中，五個模板構建出來的這個src目錄都是同樣的，只是在webpack模板中多了components目錄用於存放公用組件。

2.webpack模板

webpack模板的工程目錄結構以下：

    ├── README.md
    ├── build
    │    ├── build.js
    │    ├── check-versions.js
    │    ├── dev-client.js
    │    ├── dev-server.js
    │    ├── utils.js
    │    ├── webpack.base.conf.js
    │    ├── webpack.dev.conf.js
    │    └── webpack.prod.conf.js
    ├── config
    │    ├── dev.env.js
    │    ├── index.js
    │    ├── prod.env.js
    │    └── test.env.js
    ├── index.html
    ├── package.json
    ├── src
    │    ├── App.vue
    │    ├── assets
    │    │    └── logo.png
    │    ├── components
    │    │    └── Hello.vue
    │    └── main.js
    ├── static
    └── test
          ├── e2e
          │    ├── custom-assertions
          │    │    └── elementCount.js
          │    ├── nightwatch.conf.js
          │    ├── runner.js
          │    └── specs
          │          └── test.js
          └── unit
                ├── index.js
                ├── karma.conf.js
                └── specs
                      └── Hello.spec.js

這個webpack模板的結構是很是合理的，並且配置的工具也至關豐富，當投入真正的項目開發時會以爲模板的實用性很強。

因此咱們頗有必要花些時間將這個模板的結構以及它所提供的工具配置瞭解清楚，掌握Vue官方團隊對項目開發的環境配置與使用思路，以便於咱們能結合本身的實際狀況進行適當的配置與調整。

在上文中咱們已經提過src目錄的用法與約定，此處就再也不贅述。在項目的根目錄下多了4個目錄，它們的做用分別以下：

●　build——存放用於編譯用的webpack配置與相關的輔助工具代碼；

●　config——存放三大環境配置文件，用於設定環境變量和必要的路徑信息；

●　test——存放E2E測試與單元測試文件以及相關的配置文件；

●　static——存放項目所須要的其餘靜態資源文件；

●　dist——存放運行npm run build指令後的生產環境輸出文件，可直接部署到服務器對應的靜態資源文件夾內，該文件夾只有在運行build以後纔會生成。

可見，這些目錄的存在是依賴於模板內配置的開發工具的，webpack模板配置如下的工具。

3.構建工具

因爲開發、測試與生產三大運行環境都須要進行構建，並且針對不一樣的環境要求，它的配置會有必定的區別，後面的學習中咱們會對具體的配置進行一些定製與修改，咱們應該清楚地瞭解webpack模板是如何進行構建的。

● 編譯開發環境

在開發環境下經過如下指令加載運行Vue項目：

 $ npm run dev

這個指令的配置是在package.json的script屬性中設置的，實質上它是由npm來引導執行入口程序dev-server.js完成如下的加載過程：

(1) 加載環境變量

該環節從config目錄加載index.js和dev.env.js兩個模塊，準備開發調試環境所必需的一些目錄和全局變量。

(2) 合併webpack配置

在build目錄下一共有三個webpack的配置文件：

webpack.base.conf.js——公用的基本webpack配置；

webpack.dev.conf.js——開發環境專用的webpack配置項；

webpack.prod.conf.js——生產環境專用的webpack配置項。

這裏使用了一個叫webpack-merge的包來進行兩個webpack配置之間的合併，這個環節就是經過這個包將webpack.base.conf.js和webpack.dev.conf.js合併成最終的webpack配置。

(3) 配置熱加載

熱加載是一個很是棒的功能，這個功能啓用後的效果就是：當開發環境被啓動並進入調試模式後，一旦咱們修改了任意地方的源代碼，瀏覽器中對應的內容就會被自動刷新，而無須手工對瀏覽器進行刷新的操做，這個配置將是咱們作頁面佈局或者功能調整時的一大臂助。

上一個環境中合併的webpack配置也是經過這個環節被動態加載的，當代碼文件發生變化，熱加載就會啓動webpack進行從新編譯，而後將最新的編譯文件從新加載到瀏覽器中。

(4) 配置代理服務器

這個環境是爲咱們的代碼增長一個模擬的服務端作準備，有了它的存在，咱們就能夠在沒有後端程序支持的狀況下，直接模擬遠程服務器執行的一些請求的效果。例如，向服務器發出一個HTTP GET/api/books/的請求，那麼咱們就能夠利用代理服務器將這一請求截獲下來，而後返回一組這個API應該執行成功的返回結果，這樣咱們的前端程序運行起來的效果就與接入了服務端後的效果是一致的了。咱們將這一技術稱爲服務模擬，在後面的學習中會具體介紹這一技術。

(5) 配置靜態資源

將圖片、字體、樣式表和編譯後的JS腳本等，生成對應的一些印記（Footprint）並存放到由開發服務器託管的一個static虛目錄中，使得咱們在瀏覽器中能夠正常訪問到這些資源。每一個生成的文件Footprint是一些哈希代碼，當文件內容發生變化時這些哈希代碼就會發生改變，使用Footprint是將靜態文件發佈到CDN或者進行離線緩衝時通知瀏覽器文件是否發生改變的重要依據。

 

(6) 加載開發服務器

啓動一個Express的Web服務器，將上述各個環境中配置好的模塊進行加載，並使程序能經過瀏覽器進行訪問。

以上就是npm run dev的完整執行思路。

● 編譯生產環境

當項目準備發佈時，在命令行鍵入：

 $ npm run build

執行效果以下：

生產環境的構建過程比較簡單，首先是對必要的資源文件進行打包加上FootPrint，而後是對腳本進行編譯、壓縮和包大小的分割。