To stop having to change configuration settings in production code and to stop secure information like usernames and password being stored in source control its a good idea to use local configuration files.
This lesson explains how to read in the local configuration, how to perform a check to make sure the required variables are present and how you might communicate an example configuration file to other team members.
Instructor: [00:00] To get configuration variables into our Node application, the first thing we're going to do is reference and install a package called .ENV. You pass it the path of the variables file. I'm also going to include a logger function that I've built, and you'll be able to see this in the repository. Basically, it just allows me to output to the console or to an external third-party logging tool.
[00:31] The variables file, which is holding your config information, is just basically named pairs. Typically, you could have a node, and it's called environment, it calla something, perhaps the port the Node server's running on.
[00:43] Often, you'd have database information, username and passwords. The key thing here is that this information is not put into your source control. The way we would do that is we would have a Git ignore file. My Git ignore file looks like this. We have node_modules and variables.env, which is what I've called my file.
[01:07] Going back to my server file, to access any of these variables, I just need to use the process.env.name, of the variable I want to use. In the case of a user, it could be user. Let's just log that out for a second. I will use my logger method and we'll use some backticks. Let's start our server, and we should get the user information coming up. We do, that's what's held in our variables file.
[01:42] The next thing we want to do is, I want to make sure that all the variables are present in my local variables file before starting the server. We're going to create a setup function. I'm going to include my logger.
[01:54] I'm going to use the colors package, because I want to emphasize on my console if there's an issue. We'll have an initial function, let's call it init, and we'll log the fact that we're starting. In debug mode, we will put checking variables file, and we might extend this initial setup routine.
[02:18] I'm just going to call out to another function, just to keep it nice and separated. Then once our setup's finished, we'll also console that out. This function, which is going to be called checkVariables. It's going to take an array of constants that need to be checked. You would need to maintain this list, but it's worth it to prevent issues, especially if you're sharing the project with other developers.
[02:58] We'll set an initial haveError flag to false to start with, and then we'll loop over the variables. We check to see if this value is in the environment. If not, we will flag our error flag to true. We'll also output an error to the console, again, using our logger function. We're going to make it nice and obvious, using a background color. If we do have an error, we're going to throw it.
[03:41] That's our setup completed. Let's now add it to our server file. We can get rid of this logger message, and we're going to reference our setup routine. Remember, we're going to throw an error if this doesn't work. We're going to do a try-catch, and we're calling the init routine. If there is an error, we'll catch it. This will be a critical error, so we actually want the application to stop.
[04:05] We're going to call the Node process.exit method. If we get past that point, then the server can start. Let's run the server and see how it works. I'll start our server, and the setup routine's run successfully, no errors. Let's remove something from our variables file. We'll take out the DB address and the password.
[04:32] Run it again, and this time, we've got an error. It's quite obviously why we've got an error, which is important. That's good. The idea is, the variables file is local to you when you're doing development, and therefore, it mustn't go to Git, which is why we've got it in the Git ignore.
[04:49] To help out developers when you initially start your project, it's worth taking a copy and renaming it to something more, I normally call it examples.variable file. That way, that gives them a base. It's important that they understand that it's just literally an initial variables file. You may actually have to end up maintaining it.
[05:11] OK, that's it. That should be a good way of working with a local variables file.
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
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!