webpack-dev-server核心概念案例詳解
webpack-dev-server 核心概念
Webpack 的 ContentBase vs publicPath vs output.path
webpack-dev-server 會使用當前的路徑作為請求的資源路徑（所謂
當前的路徑
就是執行 webpack-dev-server 這個命令的路徑，如果對 webpack-dev-server 進行了包裝，比如 wcf，那麼當前路徑指的就是執行 wcf 命令的路徑，一般是專案的根路徑），但是讀者可以通過指定 content-base 來修改這個預設行為：
webpack-dev-server --content-base build/
這樣 webpack-dev-server 就會使用 build 目錄下的資源來處理靜態資源的請求，如 / 圖片等。content-base 一般不要和 publicPath、output.path 混淆掉。其中 content-base 表示靜態資源的路徑是什麼，比如下面的例子：
<!DOCTYPE html> <html> <head> <title></title> <link rel="stylesheet" type="text/css" href="index.css" rel="external nofollow" > </head> <body> <div id="react-content">這裡要插入 內容</div> </body> </html>
在作為 html-webpack-plugin 的 template 以後，那麼上面的 index.css 路徑到底是什麼？是相對於誰來說？上面已經強調了：如果在沒有指定 content-base 的情況下就是相對於當前路徑來說的，所謂的當前路徑就是在執行 webpack-dev-server 目錄來說的，所以假如在專案根路徑運行了這個命令，那麼就要保證在專案根路徑下存在該 index.css 資源，否則就會存在 html-webpack-plugin 的 404 報錯。當然，為了解決這個問題，可以將 content-base 修改為和 html-webpack-plugin的html 模板一樣的目錄。
上面講到 content-base 只是和靜態資源的請求有關，那麼我們將其 publicPath 和 output.path 做一個區分。
首先：假如將 output.path 設定為build（這裡的 build 和 content-base 的 build 沒有任何關係，請不要混淆），要知道 webpack-dev-server 實際上並沒有將這些打包好的 bundle 寫到這個目錄下，而是存在於記憶體中的，但是我們可以假設（注意這裡是假設）其是寫到這個目錄下的。
然後：這些打包好的 bundle 在被請求的時候，其路徑是相對於配置的publicPath來說的，publicPath 相當於虛擬路徑，其對映於指定的output.path。假如指定的 publicPath 為 "/assets/"，而且 output.path 為 "build"，那麼相當於虛擬路徑 "/assets/" 對應於 "build"（前者和後者指向的是同一個位置），而如果 build 下有一個 "index.css"，那麼通過虛擬路徑訪問就是/assets/index.css。
最後：如果某一個記憶體路徑（檔案寫在記憶體中）已經存在特定的 bundle，而且編譯後記憶體中有新的資源，那麼我們也會使用新的記憶體中的資源來處理該請求，而不是使用舊的 bundle！比如有一個如下的配置：
module.exports = {
entry: {
app: ["./app/main.js"]
},output: {
path: path.resolve(__dirname,"build"),publicPath: "/assets/",//此時相當於/assets/路徑對應於 build 目錄，是一個對映的關係
filename: "bundle.js"
}
}
那麼我們要訪問編譯後的資源可以通過 localhost:8080/assets/bundle.js 來訪問。如果在 build 目錄下有一個 html 檔案，那麼可以使用下面的方式來訪問 js 資源：
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title> </head> <body> <script src="assets/bundle.js"></script> </body> </html>
此時會看到控制檯輸出如下內容：
enter image description here
主要關注下面兩句輸出：
Webpack result is served from /assets/
Content is served from /users/…./build
之所以是這樣的輸出結果是因為設定了 contentBase 為 build，因為執行的命令為webpack-dev-server --content-base build/。所以，一般情況下：如果在 html 模板中不存在對外部相對資源的引用，我們並不需要指定 content-base，但是如果存在對外部相對資源 css/ 圖片的引用，可以通過指定 content-base 來設定預設靜態資源載入的路徑，除非所有的靜態資源全部在當前目錄下。
webpack-dev-server 熱載入（HMR）
為 webpack-dev-server 開啟 HMR 模式只需要在命令列中新增--hot，它會將 HotModuleReplacementPlugin 這個外掛新增到 webpack 的配置中去，所以開啟 HotModuleReplacementPlugin 最簡單的方式就是使用 inline 模式。在 inline 模式下，只需要在命令列中新增--inline --hot就可以自動實現。
這時候 webpack-dev-server 就會自動新增 webpack/hot/dev-server 入口檔案到配置中，只是需要訪問下面的路徑就可以了 http://«host»:«port»/«path»。在控制檯中可以看到如下的內容
其中以 [HMR] 開頭的部分來自於 webpack/hot/dev-server 模組，而以[WDS]開頭的部分來自於 webpack-dev-server 的客戶端。下面的部分來自於 webpack-dev-server/client/index.js 內容，其中的 log 都是以 [WDS] 開頭的：
function reloadApp() {
if(hot) {
log("info","[WDS] App hot update...");
window.postMessage("webpackHotUpdate" + currentHash,"*");
} else {
log("info","[WDS] App updated. Reloading...");
window.location.reload();
}
}
而在 webpack/hot/dev-server 中的 log 都是以 [HMR] 開頭的（它是來自於 Webpack 本身的一個 plugin）：
if(!updatedModules) {
console.warn("[HMR] Cannot find update. Need to do a full reload!");
console.warn("[HMR] (Probably because of restarting the webpack-dev-server)");
window.location.reload();
return;
}
那麼如何在 nodejs 中使用 HMR 功能呢？此時需要修改三處配置檔案：
1.新增一個 Webpack 的入口點，也就是 webpack/hot/dev-server
2.新增一個 new webpack.HotModuleReplacementPlugin() 到 webpack 的配置中
3.新增 hot:true 到 webpack-dev-server 配置中，從而在服務端啟動 HMR（可以在 cli 中使用 webpack-dev-server --hot）
比如下面的程式碼就展示了 webpack-dev-server 為了實現 HMR 是如何處理入口檔案的:
if(options.inline) {
var devClient = [require.resolve("../client/") + "?" + protocol + "://" + (options.public || (options.host + ":" + options.port))];
//將 webpack-dev-server 的客戶端入口新增到的 bundle 中，從而達到自動重新整理
if(options.hot)
devClient.push("webpack/hot/dev-server");
//這裡是 webpack-dev-server 中對 hot 配置的處理
[].concat(wpOpt).forEach(function(wpOpt) {
if(typeof wpOpt.entry === "object" && !Array.isArray(wpOpt.entry)) {
Object.keys(wpOpt.entry).forEach(function(key) {
wpOpt.entry[key] = devClient.concat(wpOpt.entry[key]);
});
} else {
wpOpt.entry = devClient.concat(wpOpt.entry);
}
});
}
滿足上面三個條件的 nodejs 使用方式如下：
var config = require("./webpack.config.js");
config.entry.app.unshift("webpack-dev-server/client?http://localhost:8080/","webpack/hot/dev-server");
//條件一（添加了 webpack-dev-server 的客戶端和 HMR 的服務端）
var compiler = webpack(config);
var server = new webpackDevServer(compiler,{
hot: true //條件二（--hot 配置，webpack-dev-server 會自動新增 HotModuleReplacementPlugin）
...
});
server.listen(8080);
webpack-dev-server 啟動 proxy 代理
webpack-dev-server 使用
http-proxy-middleware
去把請求代理到一個外部的伺服器，配置的樣例如下：
proxy: {
'/api': {
target: 'https://other-server.example.com',secure: false
}
}
// In webpack.config.js
{
devServer: {
proxy: {
'/api': {
target: 'https://other-server.example.com',secure: false
}
}
}
}
// Multiple entry
proxy: [
{
context: ['/api-v1/**','/api-v2/**'],target: 'https://other-server.example.com',secure: false
}
]
這種代理在很多情況下是很重要的，比如可以把一些靜態檔案通過本地的伺服器載入，而一些 API 請求全部通過一個遠端的伺服器來完成。還有一個情景就是在兩個獨立的伺服器之間進行請求分割，如一個伺服器負責授權而另外一個伺服器負責應用本身。下面給出日常開發中遇到的一個例子：
(1)有一個請求是通過相對路徑來完成的，比如地址是 "/msg/show.htm"。但是，在日常和生產環境下前面會加上不同的域名，如日常是 you.test.com 而生產環境是 you.inc.com。
（2）那麼比如現在想在本地啟動一個 webpack-dev-server，然後通過 webpack-dev-server 來訪問日常的伺服器，而且日常的伺服器zUvqM地址是 11.160.119.131，所以會通過如下的配置來完成：
devServer: {
port: 8000,proxy: {
"/msg/show.htm": {
target: "http://11.160.119.131/",secure: false
}
}
}
此時當請求 "/msg/show.htm" 的時候，其實請求的真實 URL 地址為 "http//11.160.119.131/msg/show.htm"。
（3）在開發環境中遇到一個問題，那就是：如果本地的 devSzUvqMerver 啟動的地址為： "http://30.11.160.255:8000/" 或者常見的 "http://0.0.0.0:8000/" ，那麼真實的伺服器會返回一個 URL 要求登入，但是，將本地 devServer 啟動到 localhost 上就不存在這個問題了（一個可能的原因在於 localhost 種上了後端需要的 cookie，而其他的域名沒有種上 cookie，導致代理伺服器訪問日常伺服器的時候沒有相應的 cookie，從而要求許可權驗證）。其中指定 localhost 的方式可以通過
wcf
來完成，因為 wcf 預設可以支援 IP 或者 localhost 方式來訪問。當然也可以通過新增下面的程式碼來完成：
devServer: {
port: 8000,host:'localhost',proxy: {
"/msg/show.htm": {
target: "http://11.160.119.131/",secure: false
}
}
}
（4）關於 webpack-dev-server 的原理，讀者可以檢視“反向代理為何叫反向代理”等資料來了解，其實正向代理和反向代理用一句話來概括就是：“正向代理隱藏了真實的客戶端，而反向代理隱藏了真實的伺服器”。而 webpack-dev-server 其實扮演了一個代理伺服器的角色，伺服器之間通訊不會存在前端常見的同源策略，這樣當請求 webpack-dev-server 的時候，它會從真實的伺服器中請求資料，然後將資料傳送給你的瀏覽器。
browser => localhost:8080(webpack-dev-server無代理) => http://you.test.com browser => localhost:8080(webpack-dev-server有代理) => http://you.test.com
上面的第一種情況就是沒有代理的情況，在 localhost:8080 的頁面通過前端策略去訪問 http://you.test.com 會存在同源策略，即第二步是通過前端策略去訪問另外一個地址的。但是對於第二種情況，第二步其實是通過代理去完成的，即伺服器之間的通訊，不存在同源策略問題。而我們變成了直接訪問代理伺服器，代理伺服器返回一個頁面，對於頁面中某些滿足特定條件前端請求（proxy、rewrite配置）全部由代理伺服器來完成，這樣同源問題就通過代理伺服器的方式得到了解決。
（5）上面講述的是 target 是 IP 的情況，如果 target 要指定為域名的方式，可能需要繫結 host。比如下面繫結的 host：
11.160.119.131 youku.min.com
那麼下面的 proxy 配置就可以採用域名了：
devServer: {
port: 8000,proxy: {
"/msg/show.htm": {
target: "http://youku.min.com/",secure: false
}
}
}
這和 target 繫結為 IP 地址的效果是完全一致的。總結一句話：“target 指定了滿足特定 URL 的請求應該對應到哪臺主機上，即代理伺服器應該訪問的真實主機地址”。
其實 proxy 還可以通過配置一個 bypass() 函式的返回值視情況繞開一個代理。這個函式可以檢視 HTTP 請求和響應及一些代理的選項。它返回要麼是 false 要麼是一個 URL 的 path，這個 path 將會用於處理請求而不是使用原來代理的方式完成。下面例子的配置將會忽略來自於瀏覽器的 HTTP 請求，它和 historyApiFallback 配置類似。瀏覽器請求可以像往常一樣接收到 html 檔案，但是 API 請求將會被代理到另外的伺服器：
proxy: {
'/some/path': {
target: 'https://other-server.example.com',secure: false,bypass: function(req,res,proxyOptions) {
if (req.headers.accept.indexOf('html') !== -1) {
console.log('Skipping proxy for browser request.');
return '/index.html';
}
}
}
}
對於代理的請求也可以通過提供一個函式來重寫，這個函式可以檢視或者改變 HTTP 請求。下面的例子就會重寫 HTTP 請求，其主要作用就是移除 URL 前面的 /api 部分。
proxy: {
'/api': {
target: 'https://other-server.example.com',pathRewrite: {'^/api' : ''}
}
}
其中 pathRewrite 配置來自於 http-proxy-middleware。更多配置可以檢視
http-proxy-middleware 官方文件。
historyApiFallback 選項
當使用 HTML 5 的 history API 的時候，當 404 出現的時候可能希望使用 index.html 來作為請求的資源，這時候可以使用這個配置 :historyApiFallback:true。然而，如果修改了 output.publicPath，就需要指定重定向的 URL，可以使用 historyApiFallback.index 選項。
// output.publicPath: '/foo-app/'
historyApiFallback: {
index: '/foo-app/'
}
使用 rewrite 選項可以重新設定靜態資源
historyApiFallback: {
rewrites: [
// shows views/landing.html as the landing page
{ from: /^\/$/,to: '/views/landing.html' },// shows views/subpage.html for all routes starting with /subpage
{ from: /^\/subpage/,to: '/views/subpage.html' },// shows views/404.html on all other pages
{ from: /./,to: '/views/404.html' },],},
使用 disableDotRule 來滿足一個需求，即如果一個資源請求包含一個
.符號，那麼表示是對某一個特定資源的請求，也就滿足 dotRule。我們看客棧看
connect-history-api-fallback 內部是如何處理的：
if (parsedUrl.pathname.indexOf('.') !== -1 &&
options.disableDotRule !== true) {
logger(
'Not rewriting',req.method,req.url,'because the path includes a dot (.) character.'
);
return next();
}
rewriteTarget = options.index || '/index.html';
logger('Rewriting','to',rewriteTarget);
req.url = rewriteTarget;
next();
};
也就是說，如果是對絕對資源的請求，也就是滿足 dotRule，但是 disableDotRule(disable dot rule file request)為 false，表示我們會自己對滿足 dotRule 的資源進行處理，所以不用定向到 index.html 中！如果 disableDotRule 為 true 表示不會對滿足 dotRule 的資源進行處理，所以直接定向到 index.html！
history({
disableDotRule: true
})
webpack-dev-server 更多配置
var server = new WebpackDevServer(compiler,{
contentBase: "/path/to/directory",//content-base 配置
hot: true,//開啟 HMR，由 webpack-dev-server 傳送 "webpackHotUpdate" 訊息到客戶端程式碼
historyApiFallback: false,//單頁應用 404 轉向 index.html
compress: true,//開啟資源的 gzip 壓縮
proxy: {
"**": "http://localhost:9090"
},//代理配置，來源於 http-proxy-middleware
setup: function(app) {
//webpack-dev-server 本身是 Express 伺服器可以新增自己的路由
// app.get('/some/path',function(req,res) {
// res.json({ custom: 'response' });
// });
},//為 Express 伺服器的 express.static 方法配置引數 http://expressjs.com/en/4x/api.html#express.static
staticOptions: {
},//在 inline 模式下用於控制在瀏覽器中列印的 log 級別，如`error`,`warning`,`info` or `none`.
clientLogLevel: "info",//不在控制檯列印任何 log
quiet: false,//不輸出啟動 log
noInfo: false,//webpack 不監聽檔案的變化，每次請求來的時候重新編譯
lazy: true,//檔名稱
filename: "bundle.js",//webpack 的 watch 配置，每隔多少秒檢查檔案的變化
watchOptions: {
aggregateTimeout: 300,poll: 1000
},//output.path 的虛擬路徑對映
publicPath: "/assets/",//設定自定義 http 頭
headers: { "X-Custom-Header": "yes" },//打包狀態資訊輸出配置
stats: { colors: true },//配置 https 需要的證書等
https: {
cert: fs.readFileSync("path-to-cert-file.pem"),key: fs.readFileSync("path-to-key-file.pem"),cacert: fs.readFileSync("path-to-cacert-file.pem")
}
});
server.listen(8080,"localhost",function() {});
// server.close();
上面其他配置中，除了 filename 和 lazy 外都是容易理解的，那麼下面繼續分析下 lazy 和 filename 的具體使用場景。我們知道，在 lazy 階段 webpack-dev-server 不是呼叫 compiler.watch 方法，而是等待請求到來的時候才會編譯。原始碼如下：
startWatch: function() {
var options = context.options;
var compiler = context.compiler;
// start watching
if(!options.lazy) {
var watching = compiler.watch(options.watchOptions,share.handleCompilerCallback);
context.watching = watching;
//context.watching 得到原樣返回的 Watching 物件
} else {
//如果是 lazy，表示我們不是 watching 監聽，而是請求的時候才編譯
context.state = true;
}
}
呼叫 rebuild 的時候會判斷 context.state。每次重新編譯後在 compiler.done 中會將 context.state 重置為 true!
rebuild: function rebuild() {
//如果沒有通過 compiler.done 產生過 Stats 物件，那麼設定 forceRebuild 為 true
//如果已經有 Stats 表明以前 build 過，那麼呼叫 run 方法
if(context.state) {
context.state = false;
//lazy 狀態下 context.state 為 true，重新 rebuild
context.compiler.run(share.handleCompilerCallback);
} else {
context.forceRebuild = true;
}
},
下面是當請求到來的時候我們呼叫上面的 rebuild 繼續重新編譯：
handleRequest: function(filename,processRequest,req) {
// in lazy mode,rebuild on bundle request
if(context.options.lazy && (!context.options.filename || context.options.filename.test(filename)))
share.rebuild();
//如果 filename 裡面有 hash，那麼通過 fs 從記憶體中讀取檔名，同時回撥就是直接傳送訊息到客戶端!!!
if(HASH_REGEXP.test(filename)) {
try {
if(context.fs.statSync(filename).isFile()) {
processRequest();
return;
}
} catch(e) {
}
}
share.ready(processRequest,req);
//回撥函式將檔案結果傳送到客戶端
},
其中 processRequest 就是直接把編譯好的資源傳送到客戶端：
function processRequest() {
try {
var stat = context.fs.statSync(filename);
//獲取檔名
if(!stat.isFile()) {
if(stat.isDirectory()) {
filename = pathJoin(filename,context.options.index || "index.html");
//檔名
stat = context.fs.statSync(filename);
if(!stat.isFile()) throw "next";
} else {
throw "next";
}
}
} catch(e) {
return goNext();
}
// server content
// 直接訪問的是檔案那麼讀取，如果是資料夾那麼要訪問資料夾
var content = context.fs.readFileSync(filename);
content = shared.handleRangeHeaders(content,req,res);
res.setHeader("Access-Control-Allow-Origin","*");
// To support XHR,etc.
res.setHeader("Content-Type",mime.lookup(filename) + "; charset=UTF-8");
res.setHeader("Content-Length",content.length);
if(context.options.headers) {
for(var name in context.options.headers) {
res.setHeader(name,context.options.headers[name]);
}
}
// Express automatically sets the statusCode to 200,but not all servers do (Koa).
res.statusCode = res.statusCode || 200;
if(res.send) res.send(content);
else res.end(content);
}
}
所以，在 lazy 模式下如果我們沒有指定檔名 filename，即每次請求的是那個 Webpack 輸出檔案（chunk），那麼每次都是會重新 rebuild 的！但是如果指定了檔名，那麼只有訪問該檔名的時候才會 rebuild!
到此這篇關於webpack-dev-server核心概念案例詳解的文章就介紹到這了,更多相關webpack-dev-server核心內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！