這兩天為了這個問題, Gitter 上問, Twitter 上問, GitHub 上問, 兩天沒反應
原來寫博客的 jlongster 不理我, 我也不知道 Webpack 作者的聯系方式
最後在 Gitter 上發的消息他似乎看到了, 就粗略地解釋了一遍, 醍醐灌頂啊...
https://github.com/webpack/docs/issues/45#issuecomment-149793458
Here is the process in short: Compile the server code with webpack Use target: "node" or target: "async-node" Enabled HMR via --hot or HotModuleReplacementPlugin Use webpack/hot/poll or webpack/hot/signal The first polls the fs for updates (easy to use) The second listens for a process event to check for updates (you need a way to send the signal) Run the bundle with node. You can't use existing HMR loaders like react-hot-loader or style-loader because they make no sense in a server environment. Just add manuall replacement code at the correct location (i. e. accept request handler like in the example) You can't use the webpack-dev-server. It's a server which serves assets not a runner. Just run webpack --watch and node bundle.js. I would go the webpack/hot/poll?1000 route first. It's pretty easy to use and suitable for dev environments. For production (if you want to hot update your production server) the signal approach is better suited.
原話就不翻譯了, 理解之後主要就是 Webpack 怎麼配置和腳本怎麼運行
我寫了一遍, 代碼僅僅是這麼短, 熱替換就實現了:
https://github.com/jiyinyiyong/webpack-backend-HMR-demo
其中代碼可以從 jlongster 的配置教程裡抄:
http://jlongster.com/Backend-Apps-with-Webpack--Part-II
webpack = require 'webpack'
module.exports =
entry: [
'webpack/hot/poll?1000' # <-- 輪詢更新內容的代碼
'./src/main' # <-- 項目入口
]
target: 'node' # <-- 指明編譯方式為 node
output:
path: 'build/'
filename: 'bundle.js' # <-- 編譯結果的文件名
module:
loaders: [
{test: /\.coffee/, loader: 'coffee'}
]
plugins: [
new webpack.HotModuleReplacementPlugin() # <-- 照常啟動 hot mode
]
resolve:
extensions: ['.js', '', '.coffee']
命令行環境運行的話, 注意是 webpack 而不是 webpack-dev-server
注意後台運行的 & 只是為了不阻塞, 你有兩個終端就開兩個吧
npm i webpack --watch & # <-- watch 模式 node build/bundle.js # <-- 運行的是打包結果的代碼
我寫了兩個測試文件, 一個是會修改的代碼 src/lib.coffee:
exports.data = 'code 5' exports.printSelf = -> console.log 'doing 3'
另一個入口文件 src/main.coffee 包含了處理模塊替換的代碼:
lib = require './lib' console.log lib.data lib.printSelf() counter = 0 setInterval -> counter += 1 console.log counter , 2000 if module.hot module.hot.accept './lib', -> lib = require './lib' console.log lib.data lib.printSelf()
跑一跑 Demo, 就知道效果怎麼樣了, setInterval 不受替換的干擾
而在 build/ 目錄, 每次修改都會生成一個 JSON 文件記錄修改的內容:
具體的文件內容也就是這樣, 大致可以認為包含了識別更新所需的信息:
➤➤ cat build/0.c797c084381bfeac37f7.hot-update.js
exports.id = 0;
exports.modules = {
/***/ 3:
/***/ function(module, exports, __webpack_require__) {
var counter, lib;
lib = __webpack_require__(4);
console.log(lib.data);
lib.printSelf();
counter = 0;
setInterval(function() {
counter += 1;
return console.log(counter, 3);
}, 2000);
if (true) {
module.hot.accept(4, function() {
lib = __webpack_require__(4);
console.log(lib.data);
return lib.printSelf();
});
}
/***/ }
};
其他方案
白天在網上查找方案, 順便在論壇上發了個帖子問這個事情,現成的主要兩個說明比較清楚的方案, 值得借鑒一下
一個是百度的技術博客上, 寫的大概是怎麼對 module 對象做處理,也就是手工監聽文件修改, 然後清楚模塊緩存, 重新掛載模塊
另一個似乎是對 require.extensions 做了 hack, 增加了操作和事件,當模塊文件更新時, 對應模塊自動更新, 並且 emit 一個事件,通過這樣的效果, 模塊引用的位置可以做一些處理, 使用新的代碼,這個應該說還是比較粗暴的, 畢竟不是所有的代碼都容易替換
https://github.com/rlidwka/node-hotswap
感想
考慮到我已經在 Webpack 這棵樹上吊死, 也就不打算深入研究了,也許 Node.js 官方對 lib/module.js 做下優化能搞出不錯的功能來,然而, JavaScript 畢竟不是不可變數據使用成風的社區, 比不了 Erlang,因為代碼替換就涉及到狀態更新的問題, 不好搞, 不如重啟來得省事,而重啟現在有 node-dev supervisor nodemon 三套方案任你選
對我來說, 主要是 Cumulo 方案對 WebSocket 存在巨大的依賴,現在前端開發已經能做到服務器上更新代碼, 客戶端自動更新了,
通過 Webpack 和 React 的機制, 局部更新 DOM 和純函數模塊,如果說能夠做到開發環境也能熱替換, 這對於開發效率的提升就太大了,本來覺得熱替換遙不可及的, 然而很可能是觸手可及的效率提升!
後面大概還有坑, 畢竟黑科技... 遇到再說了
有興趣可以細看下 jlongster 寫的相關的幾篇神作, 非常有幫助:
http://jlongster.com/archive