[問答] 爲何要用vue-cli3?

[問答]系列主要整理SegmentFault上面比較有價值的問題，以及個人回答

原問題

其實這個問題主要是想了解vue-cli3與vue-cli2相比是否存在一些不得不升級的好處和優勢？

產生這個問題的緣由是在試用完vue-cli3以後並無以爲好用，反而以爲束手束腳，我cli2時，webpack想怎麼配怎麼配爲何到了cli3我要在vue.config.js中配置 衆所周知vue-cli的通用配置並不適合每種狀況, 而在vue.config.js只能作增添和覆蓋，因此一直沒有用vue-cli3構建項目

因此想請教下 這個版本有沒有值得升級的優勢

個人回答

好問題，vue-cli3相對vue-cli有不少重要的更新。

首先說一些vue-cli這些工具的初衷吧: 這些工具就是爲了讓開發者可以開箱即用快速地進行應用開發而開發的，它們秉承的是「約定大於配置」思想，簡單說就是"能不配置的就不配置，你就按照個人方式來，也不要去爭論這個好很差，快速進行業務開發纔是正經事". 它們不建議你去配置，但也不會攔着你去配置。

另外Webpack對初學者並非十分友好，‘又長又臭’的配置，普通開發者很難寫入定義良好，性能優化的配置。否則就不會各類cli工具冒出來了，好比parcel，create-react-app。這些工具都宣稱零配置，目的就是讓開發者可以愉快的進行代碼開發。

---

如今來看看Vue-cli v3的改進，以及思考這些有什麼意義呢？

1. 抽離cli service層

Create-React-App是第一個作這種事情的。vue-cli3庫如今包含如下兩個模塊：

• CLI: 即vue全局命令，主要用於項目建立和管理，包含了vue create、vue ui這些命令。CLI命令的作的事情比較少，因此更新不會太頻繁(開發者也不多會去更新這些命令)

• Service層: 負責項目的實際構建，也就是webpack項目構建。這一塊是頻繁更新的，通常做爲項目的局部依賴。

OK，這麼作有什麼意義呢？考慮這樣一個場景，這也是答主以前遇到的一個痛點：

vue-cli3以前不算是一個構建CLI, 它頂多就是一個模板拷貝器, 作的事情很是少, 全部webpack配置和構建命令都是耦合在具體的項目裏面，package.json會包含一大堆開發依賴。

若是去跟進webpack或相關工具更新的朋友會有這種體會，升級不是一件容易的事情。好比你升級了babel-loader, 可能要連帶webpack都升級，webpack升級後可能其餘工具又不兼容了。

升級方面的痛點是其一。若是你的團隊須要維護不少項目，你怎麼對這些項目進行維護升級？每一個項目都拷貝一下？若是某個項目作了特殊配置呢？

對於團隊而言，項目構建這一塊是應該儘可能作到的統一和傻瓜化的，沒有必要在這方面投入太多的精力，應該把事情外包給擅長這種事情的人去作。

另外不要排斥更新，更新能夠得到更好的開發體驗和構建速度、運行性能, 別人在這方面比你瞭解的更多。

分離了vue-cli-service以後，項目構建更新只是一個命令的事情，除非作了不少特殊化操做。特殊化操做應該封裝到vue-cli的插件中。這就引出了vue-cli3的另一個特點：插件

---

2. 插件化

相比create-react-app, vue-cli是在太仁慈了。vue-cli的插件機制很靈活，經過webpack-chain和webpack-merge能夠實現webpack徹底定製化。

能夠對比一下市面上流行的cli工具的可擴展性：

	Vue CLI	create-react-app	parcel
快速原型開發	支持	-	支持
全局模式	零配置原型開發就是全局的	-	支持
插件	支持	-	支持，擴展文件類型和文件輸出
擴展性	強，經過插件擴展 wepack 配置	弱, 強約定, 沒法配置 webpack，能夠 eject, 而後手工配置；支持 babel-macro;(嚴格說能夠經過react-app-rewired進行擴展)	中(能夠配置 babel，postcss，Typescript); 提供了 Node API; 支持插件擴展文件類型
多頁面	支持	-	支持
適用範圍	Vue 組件的第一公民。經過擴展能夠支持任意前端框架	針對 React 開發，不支持其餘框架	parcel 是一個通用的打包工具，它的競爭對手是 webpack
編譯速度	cache-loader,thread-loader 來加速 JS 和 TS 編譯	babel-loader 開啓了 cache	編譯速度號稱是 webpack 的兩倍
可升級性	支持升級 cli-service, 插件須要單獨升級, 插件須要遵循語義化版本. 太多插件存在升級風險	支持升級 react-script, 官方維護，且強約定基本能夠保障向下兼容	支持升級 parcel-bundler
UI	圖形化管理是 CLI 的特點之一	-	-

對於vue-cli的插件實現機制能夠看這篇文章。

由於vue-cli靈活的擴展性，因此它不只限於vue自己，能夠擴展支持react、anything...

按照上文說的，若是你要作深度的vue-cli定製化，不建議直接寫在vue.config.js中，而是封裝在插件中，獨立的維護這個插件，而後項目再依賴這個插件。這樣就能夠簡化升級的成本和複雜度。

---

3. GUI界面

雖然大部分人都以爲做用不大，由於確實對開發效率並實際的提高效果。就是看着舒服直觀，這就夠了。

---

4. 快速原型開發

vue-cli3也支持直接將一個vue文件跑起來，快速原型開發或驗證某些想法時，挺不錯。

---

5. 現代模式

給先進的瀏覽器配合先進的代碼(ES6以後),同時兼容舊版本的瀏覽器，先進的代碼無論從文件體積仍是腳本解析效率、運行效率都有較高的提高。

體積對比:

Version	Size (minified)	Size (minified + gzipped)
ES2015+ (main.mjs)	80K	21K
ES5 (main.es5.js)	175K	43K

解析效率:

Version	Parse/eval time (individual runs)	Parse/eval time (avg)
ES2015+ (main.mjs)	184ms, 164ms, 166ms	172ms
ES5 (main.es5.js)	389ms, 351ms, 360ms	367ms

---

6. Standard Tooling for Vue.js Development

這是vue-cli的官方介紹，vue標準開發工具. 跟進vue-cli就是跟進官方的最佳實踐和前沿技術，vue團隊已經爲你考慮不少應用場景, why not?

---

總結一下：

• 若是咱們喜歡折騰，確定會以爲vue-cli3束手束腳，這時候咱們不是vue-cli3的目標用戶；

  就好比咱們團隊就本身搞了一一個CLI構建工具: jm-cli, 根據本身的團隊需求進行深度定製，不過咱們這個工具是強約定的，包括目錄結構、編碼規範等等. 由於咱們不推薦團隊成員去搞特殊化定製，並且爲了方便進行更新，因此乾脆就不讓擴展了，統一和規範對團隊來講纔是最重要的.

  若是你有相似的開發經驗，你會以爲vue-cli多是全部構建CLI的最終歸宿或者典範。

• 若是不想折騰，只想寫代碼, 並且想跟進vue官方最新實踐，那就直接拿來用吧；

• 若是想折騰，又要考慮團隊協做和構建工具鏈的維護成本，vue-cli是很適合的。固然你也能夠造輪子

• 若是想學webpack的構建項目，也不推薦你使用vue-cli

最後給vue團隊點個贊👍

歡迎關注我，和我交流