Hot reload plugin for node.js

[Jason Zheng]

I have built a hot-reload plugin  named 'dload'  for node.js  ,everything looks fine .(project is here : https://github.com/yyrdl/dload )

But I am not sure if it's ok for production,could somebody give any suggestions ?

Ideas :

Hot-reload means reload module when it is running , what's need to solve is :

* reload new module , and update it globally

* release the old module and the resource that is created by the module.

   If I know all  the reference of target module ,then I can update the module globally.

   

   related code in `dload`:

```js

const monitors={};
const newMonitor = funtion(tag){
  var mon={};
  monitors[tag]=mon;
  return mon;
}
exports.new = newMonitor;

```

 and useage:

```js

 const dload =require("dload");
 const mo = dload.new();// `newMonitor` return an empty Object at first ,What's important is that the object is also hold by `dload`.
 
 mo.test_module = require("./test_module.js");//load target module,and assign to the empty Object 'mo'
 
 //suppose there is a method 'say' ,just invoke it
 mo.test_module.say();

```

 Suppose something changed in `./test_module.js` ,we need to reload it . All we need to do is just remove the reference of old module in `require.cache` and `mo` ,and require target module again, at final, assign new module to `mo`. Because `mo` is also hold by `dload ` ,so it's a easy thing.

PS:Be careful with the resource created by the old module, like a connection pool or other else .

  

There are four test cases  in https://github.com/yyrdl/dload/tree/master/example :

*   `test_update_and_memory.js` : test if it will update target module successfully ,and if  it will cause memory leak.

*   `test_multi_rely.js` : test  if there is impact when reload a module which will no longer use `module1` which is also used by other modules

*   `test_module_with_status.js` test module with status ,such as an counter

*   'test_server.js'  will start a simple http server powered by express , and the only router `./server/router.js` will be changed and reload for many times. At the same time ,it will start many request at the same time to check if the reloading is work . And use another module `easy-monitor` to check if there is a memory leak .

Suggestions Wanted !  ^_^

 

[Zlatko]

Hi,

I really do not think this is production ready.

1. Simple async code.

Simple example:

// m1.js

const label = 'Hi world';

setInterval(() => console.log('From m1:', label), 1000);

exports.label = label;

// m2.js

const dload = require('../index');

const mo = dload.new();

mo.fs = require('fs');

mo.path = require('path');

mo.co = require('zco');

mo.m1 = require('./m1.js');

mo.co(function * (co_next) {

  let label = mo.m1.label;

  console.log('Old label:', label);

  setInterval(() => {

    dload.reload(mo.path.join(__dirname, './m1.js'));

    label = mo.m1.label;

    console.log('New label:', label);

  }, 1200);

})();

Run m2, then change the label manually a few times and save. All sorts of stuff in there:

From m1: Hello world

From m1: Hi worlds

From m1: Hi world

From m1: Hello world

New label: Bye bye

From m1: Hi worlds

From m1: Hi world

From m1: Hello world

From m1: Hi world

From m1: Hi world

From m1: Hello worlds

From m1: Hello world

From m1: Hello world

From m1: Hi world

From m1: Hi world

From m1: Hello world

From m1: Hi world

From m1: Hi worlds

From m1: Hello world

From m1: Hello world

From m1: Hi worlds

From m1: Hi world

From m1: Hello world

From m1: Bye bye

I know there's the _release handler, but what if my interval is not in my code, but in some library my original module required? I would be totally scared to run this in production and try reloading things when all kinds of resources are attached out there. E.g. I sometimes keep anything db-related in a separate repository. And that stuff touches say Redis, MongoDB and RabbitMQ. I know I will have to write manual _releasse code. But if I miss just one thing, it's not good. And if I let my colleagues use that? They don't even know what to release! OTOH if the server is killed, I _know_ everything is shut down. And further, even with that, let's say there's a long-running task out there. Even if you do _release, you might not be able to interrupt it properly so your resource-consuming task will keep running, _and_ you'll load a new copy of the same thing.

In this state, I'm not sure if I would even use it to hot-reload configuration variables (static, sync code), let alone async modules.

2. I guess it's early, but the docs and the API should be better. On the first read it was not clear to me what exactly I need to do. Especially since you rewrite modules in the same code where you try to explain dload. I would kick out that example and write something like this:

# Usage

const dload = require('dload');

const mo = dload.new();

mo.myHotModule = require('./my-hot-module');

// ... do some change to myHotModule, save the file

dload.reload(<path>);

// mo.myHotModule is reloaded.

Even your module name itself (dload) is confusing and not reflecting what it is for.

3. Use cases

It's not clear to me what is the usecase of this. You want to be able to load a module, use it, then _rewrite_ it from your own code, and then reload the changes? 

If I were to think of some use cases, I would say something like auto-reload is needed. Kind of like nodemon or supervisor, but reloading just those files. You'd give a list of files to watch, and then your server would not restart, only those modules would.

Or maybe you have some sandbox code, like for a live, web ide, but in that case I would never let that sandbox code in my main thread - because a simple setInterval(() => console.log()) will kill my main thread and not even let me reload the module. I'd rather spawn the sandbox code in a new process in such cases.

Such as it is, I would not use this module. If I need code reload, a simple restart is usually tollerant. And if my code is critical and I need online redeploy, I would use simple container tech for this, because that was it's purpose in the first place.

Please take the above as constructive critique. I love the idea, I just think you're not there yet (for me).

[Andrey]

I have very similar module - https://github.com/sidorares/hot-module-replacement

The only difference is that I'm trying to use same API as webpack where possible - `module.hot.accept`, `module.hot.decline`, `dispose/addDisposeHandler` - https://webpack.github.io/docs/hot-module-replacement.html

Other than similar api there is no dependency on webpack, it's just fs.watch + resolution of affected modules subgraph and triggering of registered hooks

Also happy to hear feedback!

[Jason Zheng]

Thanks for your advice .It's clear that it's not ready for production, as you say ,we will not be sure that the resource is be released completely. And it seems that it's impossible to implement a safety hot-reload-module for node.js.

I am going  to rewrite the doc , make it  more clear.  Thanks a lot !