前言
weback在web構(gòu)建工具的激烈競(jìng)爭(zhēng)中逐漸脫引而出。 無(wú)論是編譯速度、報(bào)錯(cuò)提示、可擴(kuò)展性等都給前端開(kāi)發(fā)者耳目一新的感覺(jué)。本篇文章是個(gè)人對(duì)webpack的一點(diǎn)小研究總結(jié)。
類似gulp把自己定位為stream building tools一樣，webpack把自己定位為module building system。
在webpack看來(lái)，所有的文件都是模塊，只是處理的方式依賴不同的工具而已。
webpack同時(shí)也把node的IO和module system發(fā)揮的淋漓盡致。 webpack在配合babel(ES6/7)和tsc(typescript)等DSL語(yǔ)言預(yù)編譯工具的時(shí)候，駕輕就熟，為開(kāi)發(fā)者帶來(lái)了幾乎完美的體驗(yàn)。
webpack整體架構(gòu)(以webpack.config主要部分進(jìn)行劃分)
entry:定義整個(gè)編譯過(guò)程的起點(diǎn)
output:定義整個(gè)編譯過(guò)程的終點(diǎn)
module:定義模塊module的處理方式
plugin對(duì)編譯完成后的內(nèi)容進(jìn)行二度加工
resolve.alias定義模塊的別名
無(wú)論你是jsx,tsx,html,css,scss,less,png文件，webpack一視同仁為module。并且每個(gè)文件[module]都會(huì)經(jīng)過(guò)相同的編譯工序 loader==> plugin。
關(guān)于以上這點(diǎn)，以如下一個(gè)簡(jiǎn)單的webpack.config文件為例。看下webpack會(huì)做什么
1module.exports ={2watch:true,3entry: './index.js',4devtool: 'source-map',5output: {6path: path.resolve(process.cwd(),'dist/'),7filename: '[name].js'8},9resolve: {10alias:{ jquery: 'src/lib/jquery.js', }11},12plugins: [13newwebpack.ProvidePlugin({14$: 'jquery',15_: 'underscore',16React: 'react'17}),18newWebpackNotifierPlugin()19],20module: {21loaders: [{22test: /\.js[x]?$/,23exclude: /node_modules/,24loader: 'babel-loader'25},? {26test: /\.less$/,27loaders:['style-loader', 'css-loader','less-loader']28}, {29test: /\.(png|jpg|gif|woff|woff2|ttf|eot|svg|swf)$/,30loader: "file-loader?name=[name]_[sha512:hash:base64:7].[ext]"31}, {32test: /\.html/,33loader: "html-loader?" + JSON.stringify({minimize:false})34} ]35}36};
webpack是如何處理如上webpack.config文件解析
默認(rèn)情況下就是node啟動(dòng)的工作目錄process.cwd()，當(dāng)然也可以在配置中手動(dòng)指定context。
webpack在確定webpack.config中entry的路徑依賴時(shí)，會(huì)根據(jù)這個(gè)context確定每個(gè)要編譯的文件(assets)的絕對(duì)路徑。
2.entry和output 確定webpack的編譯起點(diǎn)和終點(diǎn)
顧名思義，entry定義webpack編譯起點(diǎn)，入口模塊。 對(duì)應(yīng)的結(jié)果為compolation.assets
output定義webpack編譯的終點(diǎn)，導(dǎo)出目錄
3. module.loaders 和 module.test 確定模塊預(yù)編譯處理方式
以babel為例，當(dāng)webpack發(fā)現(xiàn)模塊名稱匹配test中的正則/js[x]?的時(shí)候。
它會(huì)將當(dāng)前模塊作為參數(shù)傳入babel函數(shù)處理，babel([當(dāng)前模塊資源的引用])。
函數(shù)執(zhí)行的結(jié)果將會(huì)緩存在webpack的compilation對(duì)象上，并分配唯一的id。
以上的這一步，非常非常關(guān)鍵。唯一的id值決定了webpack在最后的編譯結(jié)果中，是否會(huì)存在重復(fù)代碼。
而緩存在compilation對(duì)象上，則決定了webpack可以在plugin階段直接拿取模塊資源進(jìn)行二度加工。
4. plugin階段發(fā)生在webpack的module.loader處理之后，一般用來(lái)做一些優(yōu)化操作。
比如webpack.ProvidePlugin，它會(huì)在對(duì)編譯結(jié)果再加工的操作過(guò)程中進(jìn)行自定義的變量注入，當(dāng)模塊中碰到比如_這個(gè)變量的時(shí)候，webpack將從緩存的module中取出underscore模塊加載進(jìn)引用_的文件(compilation.assets)。
比如WebpackNotifierPlugin，它會(huì)在編譯結(jié)果ready的時(shí)通知開(kāi)發(fā)者，output已經(jīng)就緒。
5.resolve.alias的作用就是對(duì)module模塊提供別名，并沒(méi)有什么特殊的。
在weback經(jīng)歷以上流程的時(shí)候，查看你的內(nèi)存，你會(huì)發(fā)現(xiàn)，內(nèi)存飆升！！！
這一般都是loader階段，對(duì)DSL進(jìn)行AST抽象語(yǔ)法樹(shù)分析的時(shí)候，由于大量應(yīng)用遞歸，內(nèi)存溢出的情
況也是非常常見(jiàn)。
output目錄不是一個(gè)漸進(jìn)的編譯目錄，只有在最后compilation結(jié)果ready的時(shí)候，才會(huì)寫(xiě)入，造成開(kāi)發(fā)者等待的時(shí)候，output目錄始終為空。
【大招】 webpack將編譯結(jié)果導(dǎo)出到output是怎么做到的，為啥output不是漸進(jìn)的寫(xiě)入文件
如上，webpack在plugin結(jié)束前，將會(huì)在內(nèi)存中生成了棵巨大的文件模塊tree。
這個(gè)階段就是ready階段，webpack寫(xiě)入output目錄的分割點(diǎn)。
這棵樹(shù)的枝葉節(jié)點(diǎn)就是所有的module[由import或者require為標(biāo)志，并配備唯一moduleId],
這棵樹(shù)的主枝干就是所有的assets，也就是我們entry中的東西。
這棵樹(shù)也是webpackPlugin的處理的時(shí)候的arguments。
好吧，對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，整體而言webpack的編譯過(guò)程細(xì)節(jié)比較多，但是大體的框架還是比較直觀。
里面涉及到的類似DSL，AST的概念及模塊緩存等等，在構(gòu)建工具中還是比較常見(jiàn)的。
一切文件皆為模塊也和react的一切都可以變?yōu)镴S一樣，對(duì)前端世界帶來(lái)了新的開(kāi)發(fā)理念。
anyway,寫(xiě)webpackPlugin相對(duì)于loader而言還是比較簡(jiǎn)單的。
在寫(xiě)plugin的過(guò)程可以對(duì)webpack有個(gè)更加直觀的認(rèn)識(shí)，鼓勵(lì)多多嘗試。
最后，案例一個(gè)之前寫(xiě)的一個(gè) repowebpackPlugin編寫(xiě)
