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 !




On Tuesday, August 1, 2017 at 2:44:11 AM UTC+8, Zlatko wrote:
>
> 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).
>
>

-- 
Job board: http://jobs.nodejs.org/
New group rules: 
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/nodejs/7327cc09-2986-4d86-b70d-0d9d75ae597a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to