express-4.x-facebook-example | Express 4.x app using Passport | Authentication library

require() is a synchronous operation and blocks the event loop. As such, you generally do not want to ever be doing the first require() of a module in the middle of an actual request handler in a server because that will momentarily block the event loop.

Now, since modules are cached, only the first time you require() a module will actually take very long. But, never-the-less, it is considered a good coding practice to load your dependencies upon startup when synchronous I/O is no big deal and not during run-time.

If there were any problems with loading dependencies, you probably also want those to be discovered at server startup time, not once the server is already serving customers.

So, I think the answer to your question is yes and no. Yes, it's just fine to directly require() without assigning to variables in your startup code. No, it's not recommended to do so inside a request handler or middleware. Better to load your dependencies upon startup. Now, no great harm comes to your code if you happen to do a require() inside a request handler because only the first time actually loads if from disk and takes very long, but as a general practice, it's not the recommended way of coding just because you're trying to save a variable name somewhere.

Personally, I'd also like to know that once my server has startup, all dependencies have been successfully loaded too so there is no danger of an imperfect install being discovered later after it starts serving requests (where it may not be as obvious what went wrong and where users would see the consequences).

Here's one other thing to consider. Javascript is moving from require() to import over time and you cannot use import except at the top level of a module. You can't use it inside a statement.

Summary:

1. You want to load dependencies at startup so you don't block the event loop during actual processing of requests.
2. You want to load dependencies at startup so you discover any missing dependencies at server startup and not during server run-time.
3. Code is generally considered more reader-friendly if dependencies are obvious and easy to see for anyone who works on this module.
4. In the future when we all are using import instead of require(), import is only allowed at the top level.