webpack這個js模塊管理器(module bundler)怎麼樣?

01-03

工具主頁：webpack
它有一個亮點看上去挺吸引人的，就是能解決代碼分割（code splitting)的問題

For big web apps it』s not efficient to put all code into a single file. Especially if some blocks of code are only required under some circumstances. webpack has a feature to split your codebase into 「chunks」 which are loaded on demand. Some other bundlers call them 「layers」, 「rollups」, or 「fragments」. This feature is called 「code splitting」.
It』s an opt-in feature. You can define split points in your code base. webpack cares for the dependencies, output files and runtime stuff.

大的項目如果用requirejs或browserify管理，把所有的js都打包在一起會很臃腫，webpack似乎能解決這個問題？
（個人理解：AMD或commonJS似乎解決的是延遲載入的問題，在網路不好的情況，最理想的會不會是延遲下載或按需下載，即與其下載一個體積很大的包含所有模塊的打包（bundled and minified)文件，還不如只下載所需的模塊即可）
大家有沒有用過這個工具，這個工具用起來坑多嗎？

首先對趙同學說的『如果上線後還是一堆零散的文件，這個依賴管理工具還是趁早別做了...』不贊同，對於很多應用而言，首屏的js只佔全部js的很小一部分，如果只合併首屏js，對於其它的js做動態載入帶來的展示上的提速很明顯；另一個原因是一些庫文件極少更新，而業務文件更新頻率比較高，如果把庫文件和業務文件拆開，在客戶端也能利用上瀏覽器緩存。拆模塊不僅僅是為了開發時的方便與效率，對線上優化同樣有一定作用。

回到webpack，這確實是一個非常優秀的工具，能想到的一些功能（node端與瀏覽器端共用代碼，模塊依賴管理，代碼拆分，通過插件載入其它類型資源）webpack都有，以前我想過一個東西叫OJOC（one javascript file one component，js文件里包含組件需要的一切），webpack的loader搞搞很輕鬆就做到了。

說個意外的小坑，如果package.json格式錯誤，打包時會報 ERROR in Entry module not found: Error: Cannot resolve "file" or "directory"，讓人很摸不著頭腦，添加參數 --display-error-details 才知道是package.json解析錯誤，別的坑暫時還沒有遇到。

推薦玩一玩

看了其他人的答案，來講個不一樣的！

開發可維護的js代碼與css代碼

css模塊化；

以需求來代入：

大家在開發中是否經常會有這樣的困擾，在css的命名、復用上找不到好的解決方案。

比如有一個系統中有這樣兩個列表頁面(list)，包含需要展示的內容是大體上一樣的，但是布局展示樣式切是要求不一樣的。

比如：

平常做法

我們平時的做法是，做命名兩種css

.list-1{

.....

}

.image-1{

....

}

--------------------------------------------------------------------

.list-2{

.........

}

.image-2{

........

}

這樣做可以滿足我們的需求，但是你需要為每套布局想一個【樣式名稱】，而且我們平時寫css代碼一般放在同一個頁面內，後續不好維護。

webpack的做法

（1）解決樣式命名，為單獨的某塊寫一個css文件，通過require的形式引入樣式。如下：

兩個css文件內的樣式可以重名，webpack打包的時候生成的樣式名是模塊名_css_隨機字元(可以自定義規則)。這樣來確保兩個樣式是獨立的。如下，我們定義css名稱為.item-btn，webpack打包後，在瀏覽器下生成的樣式名如下：

js內的具體調用如下：

（2）解決樣式復用。

你可以用css模塊化裡面的compose來處理

js模塊化：

es6想必大家已經都已躍躍一試，無奈瀏覽器支持太少了。

想想es6的（promise、=&>、let ......）大家都去試一下吧，越來越像服務端語言了。

webpack打包時，通過調用babel的配置可以將我們的es6代碼轉化為es5代碼，實現瀏覽器的全兼容。

這個requirejs應該實現不了吧！

也許很快我們就看不到requirejs了吧！webpack與react

了解過react的同學，可能就會有體會了。webpack對react來說可謂開發神器。

說打包後的尺寸的話，Webpack打包的大概比requirejs的小几K吧，因為沒了require.js本身。

延遲載入與webpack並不衝突，你做N個entry然後自己處理後續載入就好，不過因為沒有了require.js或sea.js這類的依賴管理，所以得自己再實現個依賴管理或模塊管理機制。

理論上說，應該可以requirejs和webpack一起用的，先requirejs封裝再用webpack打包整合非js文件，畢竟webpack里有些工具是純粹的依賴管理庫很難做到的。

總得來說就是，工具可以去玩，但基礎還是不能落下的，基礎打好了，什麼工具有什麼好處能怎麼整合這些都不在話下。

GitHub - xiaoyu2er/awesome-webpack: webpack 資料整理

這裡有比較詳細的webpack介紹和教程，希望可以給你幫助！鏈接：https://github.com/wangning0/Autumn_Ning_Blog/blob/master/blogs/3-12/webpack.md

打包在一起是為了減少 request 數量從而能並發更多請求，提升總體載入速度，所以臃腫的一個文件本來就是目的而非副作用。如果要解決調試問題可以使用 Source Map。

所謂的代碼分割，說白了就是模塊劃分，把大文件 breakdown 的同時還能進行依賴管理，降低開發和維護的成本，而這個的好處是體現在開發時而非上線後的，如果上線後還是一堆零散的文件，這個依賴管理工具還是趁早別做了...

這個工具本身就是一個同時支持 CommonJS 和 AMD 的模塊管理實現，瀏覽器中使用的話，release 之前還是要進行 pack 的。所以你說的那個亮點...所有的模塊管理工具都是必備功能之一...真的不亮...

這兩天好好研究了下webpack。

個人感覺，如果是做單頁面應用，或者項目比較小的情況，用一下一點問題都沒有。但是如果做一個比較大的網站。頁面有幾十個的項目。我覺得用這個很不爽，很不爽，很不爽。

1.配置入口文件

每個頁面的入口文件都需要配置，如果有懶載入的，需要單配置。另外如果需要等頁面載入完畢再載入業務js的，需要通過common.js插件方式，將common.js引入到頁面，在調用webpack的jsapi。

這個我要吐槽下，很不爽。配置入口，出口很不爽。到時候這個webpack.config.js會很大。不好維護。而且我要讀配置文件才能知道我的真正源代文件在哪兒。當然我們可以約定（呵呵，又多了條不可控約束）

2.配置出口。我擦。這個要說一下。只能配置在一個文件夾下。難道項目不用分路徑的么？不分層級的么？如果可以將輸出路徑跟源文件路徑一致，這樣就好了，我不知道怎麼配置啊，知道的麻煩告訴我。

3.同時開發多個項目。啟動一個webpack-dev-server 監聽一個項目。我有倆呢？多個呢？來回切吧。這個問題到是好解決。

先寫三條吧。不過如果寫單頁面，頁面只有一個入口文件，就好玩多了。

很欣賞他的那麼多loader。把browserify和webpack的loader 然後在加上gulp ，自己在express服務。就好玩多了。

我想告訴你的是

直接看幫忙文檔就好了

學習技術最好的方式

無非是看幫忙文檔

而且官方的文檔又寫得那麼好

這裡只有強烈安利一下我這個項目了

GitHub - bodyno/react-starter-kit: 完美使用 React, Redux, and React-Router!

用了之後你就會發現你什麼都懂了

講真，確實折騰起來是個無底洞，不過功能上還是很豐富，暫時還沒有發現什麼大坑，可以算是當下前端工程化的利器了。

吐槽一點，官方文檔雖然已經不少了，還是不太夠用，特別是插件開發這塊，只能靠自己摸索。

題主說的隨著項目增大前端模塊的拆分管理問題其實不論AMD還是ES6形式都要經歷模塊分析前端構建瀏覽器本地緩存合併更新模塊請求的過程美團的移動端項目已經有針對兩種格式的實踐簡單例子在https://zhuanlan.zhihu.com/p/25012345 利用localStorage CDN combo服務就可以很好解決打包過大的問題同時項目模塊格式也可以按照需求任選。模塊粒度越精細性能越有提升，同時合理的分塊配合sourcemap也方便調試找bug

剛了解這個東西一個禮拜，真是好東西，配合typescript就跟開發本地應用程序一樣，需要什麼資源就直接用。什麼依賴，各種類型文件的載入等問題全部直接交給webpack解決，只要專心寫好commonjs就可以了。如果非要說缺點就是這東西是個重量級大黑箱，用起來沒有安全感，感覺順利的話非常方便，不過萬一碰到問題就慘了。