Webpack implémente le code Node.js à chaud remplacement_node.js

Au cours des deux derniers jours, j'ai posé des questions sur ce problème sur Gitter, Twitter et GitHub, mais il n'y a eu aucune réponse depuis deux jours
Il s'avère que le blogueur jlongster m'a ignoré, et je ne connaissais pas les coordonnées de l'auteur de Webpack
Il semblait avoir vu le dernier message posté sur Gitter, alors il l'a expliqué grossièrement. C'était tellement éclairant...
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.

Les mots originaux ne seront pas traduits. Après compréhension, l'essentiel est de savoir comment configurer Webpack et comment exécuter le script
Je l'ai réécrit. Le code est très court et le remplacement à chaud est implémenté :
https://github.com/jiyinyiyong/webpack-backend-HMR-demo
Le code peut être copié depuis le tutoriel de configuration de jlongster :
http://jlongster.com/Backend-Apps-with-Webpack--Part-II

webpack = require 'webpack'

module.exports =
 entry: [
  'webpack/hot/poll&#63;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']

Si vous utilisez un environnement de ligne de commande, veuillez noter qu'il s'agit de webpack au lieu de webpack-dev-server
Faites attention au & qui s'exécute en arrière-plan juste pour éviter le blocage. Si vous avez deux terminaux, ouvrez-en simplement deux

.

npm i
webpack --watch & # <-- watch 模式
node build/bundle.js # <-- 运行的是打包结果的代码

J'ai écrit deux fichiers de test, l'un est le code modifié src/lib.coffee :

exports.data = 'code 5'

exports.printSelf = ->
 console.log 'doing 3'

Un autre fichier d'entrée src/main.coffee contient du code pour gérer le remplacement du module :

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()

Exécutez la démo et vous connaîtrez l'effet setInterval n'est pas affecté par la substitution
Dans le répertoire build/, chaque modification générera un fichier JSON pour enregistrer le contenu modifié :

Copier le code Le code est le suivant :

➤➤ l build/
0.1dadeb2eb7b01e150126.hot-update.js 0.c1d0d73de39660806d0c.hot-update.js 2849b61a15d31ffe5e08.hot-update.json 0.99ea3ea7633f6b3750e6.hot-update.js 0.ea a7b32 3eba37ae58997.hot-update.js 9b4a5ad617ec1dbc48a3.hot-update.json fb584971920454f9ccbe . hot-update.json
0.9abf25005c61357a0ce5.hot-update.js 0.fb584971920454f9ccbe.hot-update.js a664b5851a99ac0865ca.hot-update.json
0.9b4a5ad617ec1dbc48a3.hot-update.js 1dadeb2eb7b01e150126.hot-update.json bundle.js
0.a664b5851a99ac0865ca.hot-update.js 256267122c6d325755b0.hot-update.json c1d0d73de39660806d0c.hot-update.json

Le contenu spécifique du fichier est le suivant, qui peut être grossièrement considéré comme contenant les informations nécessaires pour identifier les mises à jour :

➤➤ 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();
   });
  }

/***/ }
};

Autres forfaits

Je cherchais des solutions sur Internet pendant la journée et j'ai posté un message sur le forum posant des questions à ce sujet. Il existe deux principales solutions existantes avec des explications relativement claires, qui méritent d'être apprises

.

L'un se trouve sur le blog technologique de Baidu, qui décrit probablement comment traiter les objets du module, c'est-à-dire surveiller manuellement les modifications de fichiers, puis vider le cache du module et remonter le module
Les idées sont claires et mûrement réfléchies. Même si le code est un peu redondant, vous pouvez toujours l'essayer :
http://www.jb51.net/article/73739.htm

L'autre semble être un hack sur require.extensions, ajoutant des opérations et des événements. Lorsque le fichier du module est mis à jour, le module correspondant est automatiquement mis à jour et un événement est émis. Par cet effet, l'emplacement référencé par le. Le module peut être traité. , en utilisant un nouveau code, cela doit être considéré comme relativement grossier, après tout, tous les codes ne sont pas faciles à remplacer
https://github.com/rlidwka/node-hotswap

Impressions

Considérant que je me suis déjà accroché à l'arborescence Webpack, je n'ai pas l'intention de l'étudier en profondeur. Peut-être que Node.js optimise officiellement lib/module.js pour obtenir de bonnes fonctions. Cependant, JavaScript n'est pas la communauté où. l'utilisation de données immuables est populaire et ne peut pas être comparée à Erlang, car le remplacement du code implique le problème de la mise à jour du statut, ce qui est difficile à faire. Il est plus facile de redémarrer, et le redémarrage vous propose désormais trois options : node-dev superviseur nodemon.

Pour moi, la raison principale est que la solution Cumulo dépend énormément de WebSocket. Désormais, le développement front-end peut mettre à jour le code sur le serveur et le client se met automatiquement à jour,
. Grâce aux mécanismes de Webpack et React, le DOM et les modules de fonctions pures sont partiellement mis à jour. Si l'environnement de développement peut également être remplacé à chaud, cela améliorera considérablement l'efficacité du développement. Au départ, je pensais que le remplacement à chaud était hors de portée, mais c'est le cas. très possible. C’est une amélioration de l’efficacité à portée de main !

Il y a peut-être des pièges derrière, après tout, la technologie noire... Je vous le dirai quand vous la rencontrerez

Si vous êtes intéressé, vous pouvez regarder de plus près plusieurs chefs-d'œuvre connexes écrits par jlongster, qui sont très utiles :
http://jlongster.com/archive