[問答]系列主要整理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團隊點個贊?
歡迎關注我，和我交流