Never require Modules After App Initialization
This is to continue some of the discussion had on this issue.
I have found is that inside of a gulp file it is actually a good example where require() inside functions could be preferred. My gulp file runs various tasks like lint, watch etc. The modules needed for these tasks (e.g. gulp-eslint) are better required inside of the task. This way if the particular task is not run, the modules are not loaded.
To me the gulp file is actually a "node app" that helps setup my project for development and in production.
This becomes important when the gulp file is being used in production for installing client-side dependencies (using say bower). In this case tasks like lint are never run in production and those dependencies may not even be installed (because they are dev only dependencies in package.json). Requiring them on top will mean they can no longer be dev-only dependencies in package.json.
Now while the guide title reads Node.js-Best-Practices, the justifications in this area appear to focus on Node js web-apps where the justifications of requiring at the top of the module are good. But for other node.js apps I feel the generalization may be going too far too quickly.
My second point is about,
The second problem is a bigger problem but builds on the first. If the module you require causes an error and crashes the server you may not know about the error for several days, especially if you use this module in a rarely used route handler. No one wants a call from a client at 4AM telling them the server is down.
I see the issue here is that a bug in code is not found because the code is not frequently invoked. This could be any bug, not just a missing dependency bug. And the correct way to avoid this is to unit-test the code so that all code paths are exercised equally. I think this is just a side-effect of poorly tested code.
In conclusion
The article as it stands now does not give enough weight to the pros of requiring inside of functions, which is that the dependency does not need to be loaded, even installed, if the code that needs the module is not going to be called, which is preferable in some cases (as in development vs production environments). In all other cases the article makes a good point that requiring at the top is preferable and avoids accidental bugs and avoids delays in loading modules. But I feel it generalises the benefits for node web-apps too quickly over to other node.js (non-web) apps.
I wonder if the title should instead say "Prefer to require modules at the top of js files instead of inside function calls"?
This is to continue some of the discussion had on this issue.
I have found is that inside of a gulp file it is actually a good example where require() inside functions could be preferred. My gulp file runs various tasks like lint, watch etc. The modules needed for these tasks (e.g. gulp-eslint) are better required inside of the task. This way if the particular task is not run, the modules are not loaded.
To me the gulp file is actually a "node app" that helps setup my project for development and in production.
This becomes important when the gulp file is being used in production for installing client-side dependencies (using say bower). In this case tasks like lint are never run in production and those dependencies may not even be installed (because they are dev only dependencies in package.json). Requiring them on top will mean they can no longer be dev-only dependencies in package.json.
Now while the guide title reads Node.js-Best-Practices, the justifications in this area appear to focus on Node js web-apps where the justifications of requiring at the top of the module are good. But for other node.js apps I feel the generalization may be going too far too quickly.
My second point is about,
I see the issue here is that a bug in code is not found because the code is not frequently invoked. This could be any bug, not just a missing dependency bug. And the correct way to avoid this is to unit-test the code so that all code paths are exercised equally. I think this is just a side-effect of poorly tested code.
In conclusion
The article as it stands now does not give enough weight to the pros of requiring inside of functions, which is that the dependency does not need to be loaded, even installed, if the code that needs the module is not going to be called, which is preferable in some cases (as in development vs production environments). In all other cases the article makes a good point that requiring at the top is preferable and avoids accidental bugs and avoids delays in loading modules. But I feel it generalises the benefits for node web-apps too quickly over to other node.js (non-web) apps.
I wonder if the title should instead say "Prefer to require modules at the top of js files instead of inside function calls"?