Webpack implementation Hot code replacement

For this question these two days, I asked on Gitter, Twitter, and GitHub, but I didn't respond for two days
It turns out that the blogger jlongster ignored me, and I don’t know the contact information of the Webpack author.
Finally, he seemed to have seen the message posted on Gitter, so he explained it roughly, and it was enlightening...
/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 . 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.

I won't translate the original words. After understanding it, it mainly refers to how to configure Webpack and how to run scripts.
I wrote it once, the code is just so short, and the hot replacement is implemented:
/jiyinyiyong/webpack-backend-HMR-demo
The code can be copied from the jlongster configuration tutorial:
/Backend-Apps-with-Webpack--Part-II

webpack = require 'webpack'

 =
 entry: [
  'webpack/hot/poll?1000' # <-- Poll code for update content  './src/main' # <-- Project entrance ]
 target: 'node' # <-- Indicate the compilation method as node output:
  path: 'build/'
  filename: '' # <-- Compiled file name module:
  loaders: [
   {test: /\.coffee/, loader: 'coffee'}
  ]
 plugins: [
  new () # <-- Start hot mode as usual ]
 resolve:
  extensions: ['.js', '', '.coffee']

If the command line environment is running, please note that webpack is not webpack-dev-server
Pay attention to the background running & is just to avoid blocking. If you have two terminals, just open two.

npm i
webpack --watch &amp; # <-- watch modenode build/ # <-- The code that runs the package result

I wrote two test files, one is the code that will be modified src/:

 = 'code 5'

 = ->
  'doing 3'

Another entry file src/ contains code to handle module replacement:

lib = require './lib'

 
()

counter = 0
setInterval ->
 counter += 1
  counter
, 2000

if 
  './lib', ->
  lib = require './lib'

   
  ()

Run the demo and you will know how the effect is. setInterval is not disturbed by replacement.
In the build/ directory, each modification will generate a JSON file record of the modified content:

This is the case with the specific file content, which can be roughly considered to contain the information required to identify and update:

➤➤ cat build/0.
 = 0;
 = {

/***/ 3:
/***/ function(module, exports, __webpack_require__) {

  var counter, lib;
  lib = __webpack_require__(4);
  ();
  ();
  counter = 0;
  setInterval(function() {
   counter += 1;
   return (counter, 3);
  }, 2000);

  if (true) {
   (4, function() {
    lib = __webpack_require__(4);
    ();
    return ();
   });
  }

/***/ }
};

Other solutions

During the day, I searched for plans online and posted a post on the forum to ask about this matter. There are two ready-made plans with clearer explanations, which are worth learning from.

One is on Baidu's technical blog, which roughly describes how to process the module object, that is, manually monitor the file modification, then clarify the module cache, and remount the module
The idea is clear and meticulous, although it is a bit redundant, you can still try it:
https:///article/

Another thing seems to be hacking, adding operations and events. When the module file is updated, the corresponding module is automatically updated, and emit an event. With this effect, the module reference location can be processed. Using new code, this should be said to be relatively rough. After all, not all codes are easy to replace.
/rlidwka/node-hotswap

Feelings

Considering that I have hanged myself on the Webpack tree, I don't plan to conduct in-depth research. Maybe the official optimization of lib/ can produce good functions. However, JavaScript is not a community that uses immutable data in popularity, and it cannot compare to Erlang, because code replacement involves state update issues, which is not easy to do, so it is better to restart it. However, there are three sets of solutions for restarting, such as node-dev supervisor nodemon for you to choose.

For me, the main reason is that the Cumulo solution has a huge dependence on WebSocket. Now front-end development can update the code on the server and the client automatically updates it.
Through the Webpack and React mechanisms, DOM and pure function modules are partially updated. If the development environment can be thermally replaced, it will be too great to improve development efficiency. I originally thought that thermal replacement is out of reach, but it is likely to be an efficiency improvement within reach!

There may be some pitfalls behind it, after all, black technology... I'll talk about it if I encounter it

If you are interested, you can take a closer look at several related masterpieces written by jlongster, which are very helpful:
/archive