Using colours in a NodeJS terminal - make your output pop!

Mark Barton
InstructorMark Barton
Share this video with your friends

Social Share Links

Send Tweet
Published 6 years ago
Updated 5 years ago

Use can use colour and styles to make it easy to spot errors and group common functionality into blocks when viewing a NodeJS console.

This lesson will show how to enhance an Express application to highlight errors, display setup issues to developers and group together output using the color npm package, both in the console and Papertrail which is a hosted logging service.

We use the Colors package in this lesson.

Some other lessons which are mentioned in this video are:

Instructor: [00:00] Starting with a standard Express application with a console log output, if I start it up, you can see that the output is not very interesting, and it just says server started. If I add an error, and if I run it again, you can see that the actual output, again, is not very clear. It's not obvious what's going on.

[00:20] Let's add in some color. The first thing I'm going to do is install the colors package. Now, I'm going to add it to my project. If I run my project now, nothing yet would have changed. Still got the same output, same still for the error and the actual console.

[00:37] I'm going to be using Winston for logging into my console and also to Papertrail. It just gives much more cleaner output. I've included that as a customer logger file here. It's actually covered in another video, if you want more information about that.

[00:50] I've added a reference to my customer logger file, which is using Winston. I'm now going to add a logger output. We can see here that it's just adding logger.info with some information. If I run that now in the terminal, we have the standard console output, and then we have our logger output.

[01:07] It still hasn't got any color yet, so let's sort that out now. If we go back to our logger file, within the console logger, which is part of the Winston standard loggers, we need to add the argument colorize, and that needs to be true.

[01:21] To start with, we're going to wrap our output in a fetching green color. You start with the colors object, then the color, and then you wrap the output. We just add another bracket here. If I run the command to start server now, we can see the output is in a lovely green.

[01:41] Next, I want to show how useful colors can be for highlighting when there are issues when the application starts up. Our application is using some local configuration variables, which are not put into Git. They are created locally for each developer.

[01:54] The issue is, when a developer first starts the application, they may not have all the correct variables in place. We have a setup routine here. This setup routine will go through various things about checking the variables which should be present, and if there's an error, then reports it.

[02:11] What we're going to do is, if I run this application, and if we look at the server.js file, we can that actually, there's a setup routine, and if there's an error, the process will exit. Here, we have the routine running correctly, but this is not colorized.

[02:28] It's not actually very clear what's going on. We can do better than this. Going back to our setup routine, what I'm going to do is -- let's get rid of this side menu first -- we're going to add some color here. Again, using the colors package, I'm going to use green again.

[02:44] This time, I'm going to add an additional thing. We're going to underline it. This will make it a bit more clear what's going on, and distinguish it from our startup. We've got another output when it's finished doing its setup, so let's add another underlined green.

[03:00] Now, if I run the actual application, we should see it's a little bit more clear about what's going on. We can see that we've actually got a green underline, and this block of information could be quite big. In this case, we've only get one line.

[03:12] You can see how it's a much clearer way of identifying the setup routine. Let's make it fail, and see how we can make that even better. I've gone back into my setup routine, and I'm going to add a new variable which doesn't exist. We'll throw an error.

[03:27] If we look at the current error tracking, we have a check here. We have a logger.error. Errors to the console by default will appear red. Let's see what that looks like. As you can see, we've got error in red, but it's still not ideal. I think we can do better than this.

[03:44] Let's actually enhance this one here. What we're going to do, we're going to add colors. We're going to make the background red, because we'll make it nice and bright. We're going to make the color of the text white. The background's red, the color is white.

[03:59] This is going to make it really stand out. We'll just wrap that. Let's try it now. I'll just clear this console. There we go. It's actually very obvious that we have an error in our variables. Another useful thing that we can use color for is to easily identify when the server's running that it may be running in a test mode.

[04:21] What we're going to do is, we've got a mode inside our variables file, and we're going to check for that. If it's equal to test, we're going to make that very obvious in the console, so everyone's really aware that it's running in a test mode, this server, and shouldn't be used in production.

[04:38] You could see why, if someone released this into production, how that could be a problem, if they weren't fully aware of what was going on. We're going to again use our logger. This time, we will add the colors package.

[04:49] We're going to use yellow, and we'll use the inverse of yellow, so it's very obvious and bright what's going on. We'll add a message just to say that we are running in test mode. Let's identify it around with some stars, perhaps an uppercase.

[05:08] Let's try running that, and see what it looks like. This time, we have our warning that we're running in test mode. If a developer was running their server, they would see this fairly obviously that the server's running in test mode.

[05:24] Next, let's look at how color can help us identify blocks of code together. I've added two test roots to my Express server, one called jobs, one called pay. We're just going to output some information about when those calls been made.

[05:38] If I run the server now, I still have our original setup and caution. We're running in test mode. We're just going to call over here in the browser some of those routines. Here's a job, another job, and then perhaps a pay, pay, and a job.

[05:51] You can see, it's not necessarily easy to identify which call's been made. Let's make some color blocks in there, and that'll make it easier for us. What I'm going to do is, again, let's use the colors package. This time, let's have some white text with a background of blue. We'll wrap that text.

[06:14] Then for pay, let's do something different, just so it identifies it differently. Let's use white on, say, magenta. We'll fire our server up again, get our standard setup, and let's try some different requests. There's a job, a job, a pay, a pay, and let's just do another job.

[06:40] We can see that this now makes it much easier to identify common blocks of code. I mentioned at the beginning of the video that the actual logging output is going to an external service called Papertrail. As you can see, the colors themselves aren't really working very well.

[06:55] The one thing that does work well with Papertrail are background colors. We can see here that it's very obvious that it's much more easy to spot stuff when things are being highlighted with a background color.

[07:07] I recommend stick to background colors if you want to use an external service like Papertrail. If you go to the GitHub page for colors, which is identified here, you can see all the different colors it's capable of doing, all the different effects, including zebras and random colors. There's a lot more information on there about all the different options you have.

egghead
egghead
~ 26 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today