前端模塊打包器的開發(fā)實踐1：需求分析
前端模塊化現(xiàn)狀
分類：以Webpack，browserify的靜態(tài)分析 VS RequireJS amd模塊
（es6 的模塊我認為還是一種語法糖而已，在前端瀏覽器的支持還長時間地需要轉換器的轉換）
靜態(tài)分析以使用CommonJS方式組織代碼，指定入口文件，默認將所依賴的代碼合并到同一個文件中去，文件發(fā)送請求少。而且有一個最重要的好處就是Webpack自帶的Code Splitting 代碼分割可以允許開發(fā)者將不同的代碼組織在一起，符合前端組件化的需求。
amd模塊的模塊編寫方式是遵守amd規(guī)范的，然后通過loader（加載器）將模塊按需加載。模塊是分散的。
（這里討論問題時候只著眼于重點）
不足就是相互的優(yōu)點：
靜態(tài)分析的Webpack ， 在按需加載的實現(xiàn)頗為麻煩，甚至有一點不可行
amd模塊的編寫，文件請求次數(shù)多，只有單次依賴的模塊需要發(fā)起單獨請求。文件組織形式（由于amd模塊沒有考慮Css模塊，Html模塊的加載，在如今前端組件化組織的前景下逐漸沒意義了）唯一是Js.
需求分析
代碼分割，優(yōu)點就是能夠?qū)tml Css Js 組織在同一個文件之中。
代碼局部作用域
（上述都是組件化的需要）
模塊及依賴打包（模塊粒度的控制）
模塊的層級：
全局
局部
私有
全局一般是外部庫， 自己寫的公有庫；局部是在某幾個組件都使用的庫 ；私有：只是用一次的庫
最近很多人都在使用SPA的開發(fā)方式，但是，SPA+Router不就是MPA嗎？
由于將模塊層次分割出來，這就有了中間層（局部）模塊的按需加載需求了
正因為按需加載，所以有必要使用規(guī)范的模塊格式
模塊及依賴的識別，以及生成模塊樹
綜上所述，我們形象地說希望構建Webpack+RequireJS的一個工具
