webpack編譯zip包

⑴ webpack基本使用

step1: 創建一個項目錄
注意：項目名一般 不要帶中文
step2: 創建 package.json

或者：

step4: 處理第三方文件
html文件中需要引入多個js文件或者第三方模塊(例如：jquery.js)，只引入項目js入口文件( main.js ),其他js文件均在入口文件中導入。導致可能JS文件中使用了瀏覽器不識別的高級語法:

總結：webpack可以做兩件事情況：

step5: 配置入口文件和出口文件
每次修改js文件，手動輸入命令： webpack 入口文件路徑 -o 出口文件路徑 重新打包， 每次都要輸入入口文件和出口文件，麻煩。可以在項目目錄下建立配置文件 webpack.config.js ,指定入口文件和出口文件:

重新打包：

step6: 實現自動打包編譯
每次修改js文件，都要手動重新打包，還是麻煩？使用 webpack-dev-server 這個工具，來實現自動打包編譯的功能。

webpack-dev-server 這個工具，如果想要正常運行，要求在本地項目中必須安裝 webpack

在 package.json 文件中配置命令：

在終端中執行命令：

註：在終端執行 npm run dev ，就等於執行 webpack-dev-server 命令。這將在node中開啟一個伺服器，並且立即打包。每次修改文件，ctrl + s 保存文件,webpack-dev-server工具自動監聽文件改變，並且自動打包。

改變文件引用路徑：
執行上述命令後終端會有類似信息輸出：
【 Project is running at http://localhost:8080/ 】——webpack-dev-server工具將項目託管到localhost:8080/埠上

【webpack output is served from /】——打包好的文件通過localhost:8080/bundle.js訪問

【Content not from webpack is served from C:UsersyfbDesktop前端學習案例4.27wabpackDemo_1src】——不是通過webpack打包的文件，則是以src為根目錄訪問。

該項目根目錄下並不存在bundel.js文件，我們可以認為webpack-dev-server把打包好的文件，以一種虛擬的形式託管到了咱們項目的根目錄中，雖然我們看不到它，但是可以認為和 dist、src、node_moles平級，有一個看不見的文件，叫做 bundle.js。其實是為了頻繁打包，提高效率，直接把打包的文件放在內存中。

因為項目託管到新伺服器，現在應該訪問的是 該伺服器 下的項目，文件引用路徑也要改變:

step7: 自動打開瀏覽器進行訪問、配置埠號、指定託管的根目錄、熱重載（只是修改補丁，不重新生成整個bundle.js文件）
在 package.json 中配置命令，並重啟伺服器：

step8: 使用 html-webpack-plugin 插件
使用 --contentBase 指令的過程比較繁瑣，需要指定啟動的目錄，同時還需要修改index.html中script標簽的src屬性。

安裝 html-webpack-plugin 插件：

在 webpack.config.js 配置文件中配置插件：

html-webpack-plugin 插件的兩個作用：

step9: 處理樣式文件
html文件中需要引入css、less、sass樣式文件。默認情況下，webpack處理不了這些樣式文件。

處理css文件：

處理less樣式文件

⑵ webpack的打包配置-1修改版

1、現在本地創建項目目錄

2、然後在index.html中寫入html的結構
3、想要先安裝jquery，先npm init -y一下， npm install jquery -S 【項目目錄安裝，必須是小寫的jquery，否則會報錯】，在index.html引入main.js
4、在main.js中寫入內容如下：

使用webpack處理一下，轉換成瀏覽器可以識別的文件 ：
a: 先全局安裝一下webpack=> npm install [email protected] -g
b: 在終端中執行： webpack ./src/main.js【要處理的文件的目錄】 ./dist/bundle.js【要輸出的文件的目錄以及文件名】 ，會在dist中生成一個bundle.js文件，然後在 index.html中引入的main.js文件改成 bundle.js
這樣的話每次打包時候都需要執行 webpack ./src/main.js ./dist/bundle.js
c: 為了不手動指定入口和出口文件，在項目根目錄中新建一個webpack.config.js（基於node的，所以** **node.js的命令都可以識別）

這樣的話，就可以在終端中直接執行命令：webpack就可以直接打包了，但是還有個小問題。就是它不 會自動更新，需要手動刷新一下。下面我們就來解決這個問題。來配置webpack-dev-server

4、使用webpack-dev-server實現自動打包編譯

直接安裝webpack最高版本的時候，可能會遇到報錯的情況，如果對於版本沒有要求的話，可以降低版本：
npm install [email protected] -D 如果還會有報錯出現的話，可以試試使用cnpm安裝

需要先在終端中安裝webpack-dev-server：具體操作如下：
4.1 npm/cnpm install webpack-dev-server -D 出現下面的提示：【其實此步驟容易出現報錯，所以呢，把webpack-dev-server版本修改為@2.9.1=>[email protected]時，就不會報錯】

4.2 npm/cnpm install webpack -D 【此步驟也是容易出錯的，所以安裝的時候要和上邊的版本保持一致，[email protected]版本】
4.3 需要在package.json中配置dev

最後直接執行：npm run dev運行成功，但是需要注意的是此時打包成的bundle.js文件不是磁碟中存在bundle.js文件，而是一個與src dist node_mole同級的看不見的文件，在index.html引入的路徑也要修改以下=》<script src="/bunlde.js"></script>

此時，正常打包，但是不自動打開瀏覽器

發布出來，方便自己查看，有什麼不對的地方，希望留言糾正修改。（程序員菜鳥一枚）

⑶ 從 Webpack 到 Snowpack, 編譯速度提升十倍以上——TRPG Engine遷移小記

原文地址: http://moonrailgun.com/posts/74598ef5/

TRPG Engine 經過長久以來的迭代，項目已經顯得非常臃腫了。數分鍾的全量編譯, 每次按下保存都會觸發一次 10s 到 1m 不等的增量編譯讓我苦不堪言, 龐大的依賴使其每一次編譯都會涉及很多文件和很多包，長時的編譯時間大大降低了開發效率與迭代速度。

經過一段時間的考察，我選擇了 Snowpack 作為解決方案。與 Webpack 不同的是，除了第一次的全量編譯以外， Snowpack 的增量編譯不會涉及到龐大的 node_moles 文件夾, 准確來說只會編譯變更文件本身。甚至於如果沒有對依賴進行變更，下次的全量編譯會直接動用之前編譯的文件緩存，不需要花時間等待 node_moles 的編譯。

為什麼會這么快？這是由於 Snowpack 本身的實現與設計哲學有關的。相比 Webpack , Snowpack 利用了現代瀏覽器的本身的 mole 系統，跳過復雜的模型之間的組織編譯過程而只關注於變更文件本身的編譯，這樣當然快了。

拿 Snowpack 官方的一張圖來說:

snowpack 的最我譯單位是文件，而 webpack 的最我譯單位為 chunk , 而 chunk 還需要額外的計算, 不論是編譯部分還是編譯後的組裝部分。snowpack的設計邏輯天生決定了她的速度。

優化前(使用 webpack ):

全量編譯:

增量編譯:

全量請求用時:

優化後(使用 snowpack ):

全量編譯:

增量編譯:

(看不到編譯用時，但是體感在1s內. 而且該效果在電腦運行其他應用時更加顯著)

全量請求用時:

以上測試是保證電腦在空閑時間，且保存與操作內容為同一文件

該用時已經是平時操作的最快時間，為此我的MBR重啟了一次強制清空了swap空間, 實際表現會更加顯著

因為文件依賴於瀏覽器的耗時，而瀏覽器需要串列請求依賴，因此耗時會更加長

但實際使用中使用snowpack會更加優秀。因為其相比webpack會大大節約電腦資源。在webpack編譯時會佔用大量的電腦資源，會影響到其他操作

TRPG Engine 算是非常經典的 Webpack 應用了, 使用了各種Loader。光通用配置就有250+行，各種優化配置，各種 alias。等等長時間迭代積攢下來的配置，因此毫不意外的會遇到很多問題與坑。

以下是我遇到的問題與解決方案:

Snowpack雖然作為一個新興的打包工具，目前尚不是非常完善, 功能也沒有webpack這樣豐富與齊全。但是它的新的打包設計對於有一定規模的前端應用還是非常優秀的。能極大提升開發效率。不失為一種好的解決方案。當然最後輸出還是需要使用webpack對其進行一定的優化，畢竟原生的mole支持目前瀏覽器的支持度還沒有達到覆蓋一個理想的地步 https://caniuse.com/es6-mole

最後這是我最後提交的 pr

⑷ webpack 怎麼直接實時編譯輸出文件

使用webpack編譯打包react是非常便捷的。這也是人們常用的一種方式。但是在使用過程中，一定要注意一個細節，那就是webpack和babel-loader的安裝位置。react安裝當然，使用react必須先安裝react和react-dom，其安裝方式很簡單（前提是我們必須安裝有npm）。#npminstallreactreact-dom–savereact安裝就這樣簡單，其實react和react-dom就是相當於js類庫。但是我們需要解析器來解析react的語法。react解析器babel安裝babel安裝的位置是我們這篇文章的目的。babel有兩種安裝的位置：一種是全局安裝，一種是本地安裝——也就是安裝在項目目錄下的node_moles下。#npminstallbabel-corebabel-loaderbabel-preset-react–save-dev//本地安裝#npminstallbabel-corebabel-loaderbabel-preset-react–g//全局安裝一般情況下我們選擇本地安裝，這樣便於管理。打包工具webpack的安裝同樣，webpack的安裝位置也是這篇文章描述的所要注意的點。當然，它也有兩種安裝的位置：全局安裝和本地安裝。#npminstallwebpack–save-dev//本地安裝#npminstallwebpack–g//全局安裝如果選擇本地安裝，那麼在使用的時候較麻煩一些，我們需要在命令前加上路徑。所以一般情況下都是全局安裝，這樣就可以在任意位置直接使用。這里我們選擇全局安裝。這樣才能出現我們將要說的問題。webpack配置文件編寫安裝完webpack以後，下面來編寫webpack配置文件webpack.config.js。這里我不寫全部，只寫載入loader部分。代碼一mole:{loaders:[{test:/\.js$/,loader:'babel',query:{presets:['react']}}]}編譯過程中出現的錯誤好了，到了關鍵的地方了。現在我們整個系統的配置是這樣的：babel安裝到本地，webpack安裝到全局位置，webpack配置文件如代碼一所示。接下來我們就要編譯打包我們的項目。#webpack執行該命令以後，你會發現出現如下的錯誤：ERRORin(webpack)/~/node-libs-browser/~/process/browser.jsMolebuildfailed:Error:Couldn'tfindpreset"react"relativetodirectory"/node/lib/node_moles/webpack/node_moles/node-libs-browser/node_moles/process"……這也就是說找不到babel-preset-react。好了，說了這么多終於在這里引出了我們將要討論的問題（這里大家不要嫌我啰嗦，為什麼出現這種問題，其原因總要弄清楚。什麼樣的配置會出現這種問題，了解以後才容易上手解決）。解決問題的方式出現上述問題以後，我們有這樣三種方式可以解決。方式一要解決這個問題很簡單。我們知道，出現這個問題是因為bable和webpack安裝的位置不同，所以找不到babel-preset-react。因為在配置文件中有這樣一段代碼。query:{presets:['react']}好了，既然知道是安裝位置不同，那我們可以將babel安裝在全局位置，這樣這個問題不就解決了嗎。#npmremovebabel-corebabel-loaderbabel-preset-react–save-dev//首先移除原先安裝的babel#npminstallbabel-corebabel-loaderbabel-preset-react–g//全局安裝沒錯，問題解決了。但是我們不推薦使用這種方式。因為這樣不便於管理，所以還是使用其他的方式。方式二此種方式和方式一大同小異。方式一是改變babel的安裝位置，而這里是改變webpack的安裝位置。原先webpack是安裝到全局位置的，所以找不到安裝到本地項目目錄下的babel-preset-react。因此我們可以改變webpack的位置。#npmremovewebpack–g//移除原先的webpack#npminstallwebpack–save-dev//將webpack安裝到本地位置——也就是項目目錄下的node_moles中#ln–s/項目根目錄/node_moles/webpack/bin/webpack.js/usr/bin/webpack//為了使用webpack方便，在這里我們在/usr/bin目錄下建立軟連接（也就是快捷方式）//這樣我們就可以在任意位置直接使用webpack命令了。此時我們已經改變了webpack的安裝位置。現在二者同在項目目錄下安裝。所以可以正確編譯了。此種方式較方式一，我個人比較推薦這種方式，這樣比較方便管理。但是，這種方式也不是沒有弊端。如果我們有多個項目，那我們就需要在每個項目下都安裝webpack，那豈不是很麻煩。所以這種方式也不是很好。方式三該方式應該說是最值得推薦的，因為不需要改變webpack和babel的安裝位置。webpack還是在全局位置，babel還是在本地項目位置下。我們需要做的就是修改webpack的配置文件，在代碼一的基礎上添加一句代碼。代碼二mole:{loaders:[{test:/\.js$/,loader:'babel',exclude:/node_moles/,query:{presets:['react']}}]}

⑸ Webpack 怎麼用

1. 為什麼用 webpack?
他像 Browserify, 但是將你的應用打包為多個文件. 如果你的單頁面應用有多個頁面, 那麼用戶只從下載對應頁面的代碼. 當他么訪問到另一個頁面, 他們不需要重新下載通用的代碼.
他在很多地方能替代 Grunt 跟 Gulp 因為他能夠編譯打包 CSS, 做 CSS 預處理, 編譯 JS 方言, 打包圖片, 還有其他一些.
它支持 AMD 跟 CommonJS, 以及其他一些模塊系統, (Angular, ES6). 如果你不知道用什麼, 就用 CommonJS.
2. Webpack 給 Browserify 的同學用
對應地:
browserify main.js > bundle.js

webpack main.js bundle.js

Webpack 比 Browserify 更強大, 你一般會用 webpack.config.js 來組織各個過程:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
}
};

這僅僅是 JavaScript, 可以隨意添加要運行的代碼.
3. 怎樣啟動 webpack
切換到有 webpack.config.js 的目錄然後運行:
webpack 來執行一次開發的編譯
webpack -p for building once for proction (minification)
webpack -p 來針對發布環境編譯(壓縮代碼)
webpack --watch 來進行開發過程持續的增量編譯(飛快地!)
webpack -d 來生成 SourceMaps
4. JavaScript 方言
Webpack 對應 Browsserify transform 和 RequireJS 插件的工具稱為 loader. 下邊是 Webpack 載入 CoffeeScript 和 Facebook JSX-ES6 的配置(你需要 npm install jsx-loader coffee-loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' } // loaders 可以接受 querystring 格式的參數
]
}
};

要開啟後綴名的自動補全, 你需要設置 resolve.extensions 參數指明那些文件 Webpack 是要搜索的:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' }
]
},
resolve: {
// 現在可以寫 require('file') 代替 require('file.coffee')
extensions: ['', '.js', '.json', '.coffee']
}
};

5. 樣式表和圖片
首先更新你的代碼用 require() 載入靜態資源(就像在 Node 里使用 require()):
require('./bootstrap.css');
require('./myapp.less');

var img = document.createElement('img');
img.src = require('./glyph.png');

當你引用 CSS(或者 LESS 吧), Webpack 會將 CSS 內聯到 JavaScript 包當中, require() 會在頁面當中插入一個 ｀<style>標簽. 當你引入圖片, Webpack 在包當中插入對應圖片的 URL, 這個 URL 是由require()` 返回的.
你需要配置 Webpack(添加 loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
path: './build', // 圖片和 JS 會到這里來
publicPath: 'http://mycdn.com/', // 這個用來成成比如圖片的 URL
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.less$/, loader: 'style-loader!css-loader!less-loader' }, // 用 ! 來連接多個人 loader
{ test: /\.css$/, loader: 'style-loader!css-loader' },
{test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'} // 內聯 base64 URLs, 限定 <=8k 的圖片, 其他的用 URL
]
}
};

6. 功能開關
有些代碼我們只想在開發環境使用(比如 log), 或者 dogfooging 的伺服器里邊(比如內部員工正在測試的功能). 在你的代碼中, 引用全局變數吧:
if (__DEV__) {
console.warn('Extra logging');
}
// ...
if (__PRERELEASE__) {
showSecretFeature();
}

然後配置 Webpack 當中的對應全局變數:
// webpack.config.js

// definePlugin 接收字元串插入到代碼當中, 所以你需要的話可以寫上 JS 的字元串
var definePlugin = new webpack.DefinePlugin({
__DEV__: JSON.stringify(JSON.parse(process.env.BUILD_DEV || 'true')),
__PRERELEASE__: JSON.stringify(JSON.parse(process.env.BUILD_PRERELEASE || 'false'))
});

mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
plugins: [definePlugin]
};

然後你在控制台里用 BUILD_DEV=1 BUILD_PRERELEASE=1 webpack 編譯. 注意一下因為 webpack -p 會執行 uglify dead-code elimination, 任何這種代碼都會被剔除, 所以你不用擔心秘密功能泄漏.
7. 多個進入點(entrypoints)
比如你用 profile 頁面跟 feed 頁面. 當用戶訪問 profile, 你不想讓他們下載 feed 頁面的代碼. 因此你創建多個包: 每個頁面一個 "main mole":
// webpack.config.js
mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js' // 模版基於上邊 entry 的 key
}
};

針對 profile, 在頁面當中插入 <script src="build/Profile.js"></script>. feed 頁面也是一樣.
8. 優化共用代碼
feed 頁面跟 profile 頁面共用不要代碼(比如 React 還有通用的樣式和 component). Webpack 可以分析出來他們有多少共用模塊, 然後生成一個共享的包用於代碼的緩存.
// webpack.config.js

var webpack = require('webpack');

var commonsPlugin =
new webpack.optimize.CommonsChunkPlugin('common.js');

mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js'
},
plugins: [commonsPlugin]
};

在上一個步驟的 script 標簽前面加上 <script src="build/common.js"></script> 你就能得到廉價的緩存了.
9. 非同步載入
CommonJS 是同步的, 但是 Webpack 提供了非同步指定依賴的方案. 這對於客戶端的路由很有用, 你想要在每個頁面都有路由, 但你又不像在真的用到功能之前就下載某個功能的代碼.
聲明你想要非同步載入的那個"分界點". 比如:
if (window.location.pathname === '/feed') {
showLoadingState();
require.ensure([], function() { // 語法奇葩, 但是有用
hideLoadingState();
require('./feed').show(); // 函數調用後, 模塊保證在同步請求下可用
});
} else if (window.location.pathname === '/profile') {
showLoadingState();
require.ensure([], function() {
hideLoadingState();
require('./profile').show();
});
}

Webpack 會完成其餘的工作, 生成額外的 chunk 文件幫你載入好.
Webpack 在 HTML script 標簽中載入他們時會假設這些文件是怎你的根路徑下. 你可以用 output.publicPath 來配置.
// webpack.config.js
output: {
path: "/home/proj/public/assets", // path 指向 Webpack 編譯能的資源位置
publicPath: "/assets/" // 引用你的文件時考慮使用的地址
}

⑹ Webpack打包流程細節源碼解析（P2）

此篇博客緊承上一篇，上片討論了我們的webpack整個處理單個文件的流程，這一節主要說一說webpack的文件打包問題，其實本身是比較簡單的，但是有非同步塊和html-plugin的加入，使這個步驟變得尤為復雜，這里先介紹幾個重要的概念：

上一節中，我們成功的對每個文件進行了處理，並通過了process的方法對所有入口文件以及他們的依賴文件進行了處理，獲得了最初的依賴文件列表，現在我們就可以對資源的依賴進行優化處理，本片的內容將從webpack/lib/Compiler.js:510的斷點開始逐步的對源碼進行分析

在seal之前，由於一輪compilition已經執行完成，先調用finish方法進行收尾處理與之對應的是我們注冊的finish-moles事件，

這里我們首先看到的又是index.ejs這個老朋友，由於他是單獨的文件經過了loader處理沒有獲得額外的處理函數的依賴，所以最終這里看到的mole實際上是它的js外殼包起來的ejs文件，此階段也還沒有進行資源hash的注入等等

這里有一個FlagDependencyExportsPlugin進行了操作，聽名字可能就聽出來了，他是對我們資源中的export使用進行一個標志的作用， 和我們最終做出的tree shaking效果可能是相關的

調用seal事件處理

處理我們的preparedChunk，這個東西是我們剛好在進行addEntry的時候添加上的不知道你們還記不記得，中途就沒有添加過新的，所以講道理，一個entry是只用一個的，但是這里使用了一個數組不知道有什麼用意

然後把這個入口模塊添加到了block裡面，過後打包也是從block裡面拿數據，block裡面的東西會被打包成為單獨的文件，但是還是工作在之前的上下文中，這里可以通過看一下這里的import即是我們之前在路由文件中通過import函數設置引入的動態載入路由資源

進入到函數，就開始處理我們之前做好准備的block了，這里這是一個不斷處理依賴的過程，但是沒有使用遞歸的做法，畢竟文件太多了，不斷的進行遞歸會浪費很多空間，取而代之的是使用queue進行記錄，處理過程中不斷把新的需要處理的模塊放到queue裡面等待下一步處理

在每一步的處理中

處理完這一波循環依賴旅歷過後，本身的依賴樹結構變得扁平化，之前一層一層的模塊通過dependency連接起來作為一個樹的結構，而現在變成了頂層最終的幾個chunk

可拆正搜以看到我們最終在這個入口（entry）設置清穗中拿到了9個chunk，她們都有_moles屬性，我們的所有依賴都是放到這裡面的，是用的一個Set進行存儲，其中的依賴關系則是通過origins和reason等標識進行模塊間關系的連接的

還可以將我們的入口chunk和非同步載入的chunk進行一些對比（上面的是入口文件），下面的chunk中出現的origins就是指向我們之前的router那個mole

這個圖里也可以看到，兩個chunk實際上按照自己的路子搜集了所有的依賴，結果導致了_moles的文件數量都達到了一千多個，這就是我們常使用的CommonChunk插件需要處理的地方了，稍後進行討論

這輪處理我們成功的把主要的入口mole和非同步載入的模塊區分開了，然後開始按照類似的邏輯處理我們的第一個入口模塊

這個時候拿到chunkDependencies進行處理，這就是之前那個存儲block的東西，但是有個很奇怪的地方，就是這裡面居然只有三個chunk，而不是和上面的一樣是9個也不是只有一個入口模塊，這就讓人無從下手了（我非同步載入的模塊並不是一樣的，而且這些模塊之間沒有沒相互依賴）

喜聞樂見進行第二次處理，首先取出一個chunk拿到對應的存儲在value中的deps，對每一個項目添加上了他們的parent，但是有個組件就是用來removeParent的

在RemoveParentMolesPlugin這個插件中，針對每個mole都做了處理，看看這些模塊在哪些chunk之中有被使用到，把他們所存在的chunks按照id記錄下來，並改變她們的reason為幾種統一的chunk組合數組。這樣就做到了每個mole知道了自己被哪些chunk使用，但是從之前的單一reason到現在的多reason具體不知道有什麼用（恩。。可能是為作用域提升做准備）

然後嘛，移除空的模塊，不需要多解釋

然後這層處理就算完啦，主要進行了模塊的依賴梳理和拆分，並為他們添加上了指向父節點的指針（話說之前不是有origins嗎）

對模塊進行排序工作，不過只是按照索引進行排序罷了，那個按照出現概率進行排序處理的插件不是在這里工作的

又是那個flag的插件進行了處理，但是只是把所有模塊的used設置為了true，還有為一些被依賴的mole設置上他們的usedExports為true

ChunkConditions插件用於監視模塊上是否有chunkCondition函數，並返回他的執行結果，如果有模塊的此函數返回了false，那麼將會重寫這個模塊（重寫即是重新添加進入parent的鏈接以及reason等的設置）並且還會返回true，到至此過程不斷執行直至condition全部OK

RemoveParentMolesPlugin這個插件的作用有點玄乎，看樣子是對每個chunk進行處理，看對於多個chunk中都有的某一些mole，會直接把他們的reason設置為主要的入口chunk，而後把當前chunk中的mole移除掉（話說這個事情不是應該Common來做嗎）

然後移除所有空的模塊，再就是移除重復的模塊了（話說一直用set神他媽還會有重復的）

然後進行各種優化，比如出現的概率大的放到前面，這里還是做了mole和chunk兩種優化，也是有毛病，就像我們的react項目中可以知道react的使用次數最多，那麼他就被放到了最錢前面，緊隨其後的是echart等

HashedMoleIdsPlugin插件為我們的模塊計算出它的id，默認是通過md5進行計算，解出來的是base64的，而且計算的參數也僅僅只是通過模塊的libId進行hash，而這個libhash只是相對位置，連絕對的都不是，所以算下來這個東西能夠當成單個文件的hash了

applyMoleId，到這里你可能會想，誒之前不是已經設置好每個元素的id了嗎，為什麼還要搞這么個函數專門處理，我們在上一個生成id的時候實際上得到的id是根據我們的設置進行了截斷的，實際上拿到的hash碰撞的概率非常大，我們看看下面這個篩選的處理就可以知道，1885個模塊裡面竟然又3個重復的id，這種時候就要特殊處理了

執行sortItemsWithMoleIds依據id進行排序，不只是最外面的chunk，就連reason里的id也會被重新排序，也是蠻逗的，這里直接用的是id做比較並沒有判斷類型，也就是說把數字和字元串會混到一起，就算你是class也會拿valueOf出來比較，想想還是蠻刺激的，不過其實比較完成也沒有太特殊的用途就這么隨意一點也好

中間一些處理recordId的我忽略掉了

然後開始處理hash了，這里的hash具體使用了哪些參數和長度是多少呢

可以在此階段添加hashSalt即雜訊，給hash值添加一些特徵

進入mainTemplate的處理函數中，添加了一些字元串參數和數字參數，並且調用了mainTemplate的hash插件，但是她們的執行過程並不是保證我們最後生成的文件中能夠有結果的hash值，便於請求對應的資源文件，而是僅僅在hash的過程中添加了一些干擾的路徑參數等

最終一輪hash下來，chunk會得到自己的renderHash，而compilation會得到一個針對編譯過程的hash，這個hash就跟我們的所有資源扯上關聯啦，所以每次都是新的

創建模塊資源咯~

這些文章寫的都有點水，相當於是閱讀源碼時候做的筆記了，看看圖個樂子吧

⑺ webpack打包原理

webpack打包原理是根據文件間的依賴關系對其進行靜態分析，然後將這些模塊按指定規則生成靜態資源，當 webpack 處理程序時，它會遞歸地構建一個依賴關系圖(dependency graph)，其中包含應用程序需要的每個模塊，然後將所有這些模塊打包成一個或多個 bundle。

webpack有兩種組織模塊的依賴方式，同步、非同步。非同步依賴將作為分割點，形成一個新的塊；在優化了依賴樹之後，每一個非同步區塊都將作為一個文件被打包。

webpack有一個智能解析器，幾乎可以處理任何第三方庫。無論它們的模塊形式是CommonJS、AMD還是普通的JS文件；甚至在載入依賴的時候，允許使用動態表require("、/templates/"+name+"、jade")。

(7)webpack編譯zip包擴展閱讀

在使用webpack構建的典型應用程序或站點中，有三種主要的代碼類型：

1、團隊編寫的源碼。

2、源碼會依賴的任何第三方的library或"vendor"代碼。

3、webpack的runtime和manifest，管理所有模塊的交互。

runtime 包含：在模塊交互時，連接模塊所需的載入和解析邏輯；包括瀏覽器中的已載入模塊的連接，以及懶載入模塊的執行邏輯。