Ekmek
Ekmek

Reputation: 483

Automatically require modules in nodeJS

I'm looking for a VS code extension, or any NodeJS feature, or some JavaScript Idea of how I can automatically require particular modules for me. I have a dependency that I've created myself, it's a simple utility for logging stuff to the console, so instead of me writing all the time console.log(colors.red("Error: something went wrong")) I can simply type log.error("something went wrong"). I am now repeating myself for each file I create, I have to require("./../utils/log") (with the path being changed all the time from one file to another) for each file I create.

Is there a VS code extension, or any NodeJS feature, or some JavaScript Idea of how I can automatically require particular modules for me?

Upvotes: 1

Views: 670

Answers (2)

Vidar
Vidar

Reputation: 1238

Yes, you can require files automatically on startup either by running a setup function or using the -r command line option. Make your function available by adding it to the global object.

Create a file like this:

const colors = require('colors')

global.log = function(...args) {
  console.log(colors.red(...args))
}

and then run it on startup with node -r /path/to/file.js

You can of course also require this file manually somewhere in the setup phase of your app, and the function will be available everywhere.

In your case, since console already is global, you could extend or overwrite it:

// Add a 'red' function to console
console.red = function(...args) {
  console.log(colors.red(...args))
}
// call with console.red('hello')

Extending it is also easy:

// or overwrite the built in 'log'
const log = console.log
console.log = function(...args) {
  log(...args)
}

This last one is useful if you want to write your logs to file in production for example:

const log = console.log
console.log = function(...args) {
  if (process.env.NODE_ENV == 'production') {
    // write to log file or record event in database
  }
  log(...args)
}

I use my lowtide library in production like this to extend console.error and console.log

If I want terminal logging without writing to log files in production, I use console.info

Upvotes: 1

jfriend00
jfriend00

Reputation: 707318

The benefits of modularity in nodejs are many. The pain of modularity in nodejs is that you need to manually require() or import in every dependency for that module at the start of the module. Get used to it. It's just how you program in nodejs. Yes, it feels repetitive when coming from other environments, but it's necessary for each module to physically state and load its own dependencies in order to get the full benefit of nodejs modularity. It is worth it in the long run. Just type the dependencies at the start of each module.

After awhile, you start to appreciate that each module essentially declares what it depends on at the beginning (by loading its dependencies). And, as soon as you start writing module tests, you will really appreciate that each module is independently testable because it loads all its own dependencies and does not require some larger environment to be configured before it can be tested. The first time you decide you want to share a module into another project, you will really appreciate that it's already stand-alone and sharable. It's worth it to do this right.

I am now repeating myself for each file I create, I have to require("./../utils/log") (with the path being changed all the time from one file to another) for each file I create.

Yep, that's how things work in nodejs. Any system (probably using globals) that works around this will defeat the modularity of nodejs and then your modules won't be stand-alone, won't declare their own dependencies, won't be independently testable, wont' be independently sharable, etc... because they will have a hidden dependency on some outside environment existing before they can do their job.

The little bit of typing avoidance is not worth what you give up when you give up module independence.

FYI, your sentiment (about repeatedly typing the same thing in multiple modules) when first programming in nodejs is common. We programmers are trained to recognize code repetition and to treat that as a problem that should be solved and avoided. This is just one case where it isn't something that should be removed and the repetition leads to modules being self describing and independently testable and sharable and not dependent upon some global environment. The good that comes is much better than the bad.

Upvotes: 2

Related Questions