Digging Into Node.js

Command Line Arguments

Kyle Simpson

Kyle Simpson

You Don't Know JS
Digging Into Node.js

Check out a free preview of the full Digging Into Node.js course

The "Command Line Arguments" Lesson is part of the full, Digging Into Node.js course featured in this preview video. Here's what you'd learn in this lesson:

Kyle uses process.args to receive command line arguments, gets an array of the arguments passed in, and then demonstrates how to utilize the minimist package to place the arguments into an object with optional configuration.


Transcript from the "Command Line Arguments" Lesson

>> Kyle Simpson: Okay, let's keep moving forward with our exercise 1. We wanna do some more interesting things than just print out some static help text. First thing that we want to do is try to get some input into our program, but we're not gonna use stdin yet. So there are other ways of getting input from the outer system into our program.

And one of the most common of those is to use the command line parameters. So if we're on a command line, and we say something like ex1.js, and then we say, hello=world. That's some input, that's a command line parameter that is gonna come into our program. And we wanna be able to access that command line parameter.

So how are we gonna do that? Well, first off, what we're gonna do is access the arguments that were passed to our program by way of another of the exposures of the POSIX, which is process.args, args is plural. Process.args will be an array of all of the arguments that were passed in from the executing shell.

So if we were to do console.log(process.args), that's gonna let us see the array and see what's being passed into our program. Whoops, sorry. It's process.argv. That's probably why it was in the wrong syntax highlighting [LAUGH]. Okay, it's process.argv because that's the traditional name from the C programming. We called it argv for the list of arguments, and argc for the count.

Now when we run it, we'll see an array of the arguments. Now, you'll notice that we have two arguments at the top which we probably don't really actually care that much about. We've got the argument that is the location where my node is installed, and then the fully qualified path to my ex1.js.

That also is not something that typically your program is gonna care that much about. So what we typically will do is just slice off the first two of those, so process.argv.slice(2). And then when we run it again, we'll now see that it's just an array of the single parameter.

And of course if I were to call it again and pass in extra parameters, like that, we notice that that comes in as another entry in it. Now, there are a bunch of different conventions for how command line arguments get specified on the command line. So there's this dash dash long parameter name.

There's a single dash with a short parameter name, there's single dash with a space in between. There's a bunch of different ways that are a bunch of different conventions for the way parameters get specified. And you'll notice that none of that parsing is happening for us by node.

So we could do our own regular expression parsing and come up with the parsing rules for all those various different conventions. But that's a bunch of work that we shouldn't do ourselves. So we're gonna go back and use a package, one that's already installed for you, but the name of this package is called minimist.

So we're gonna grab minimist. We're gonna just do require("minimist"). And what that comes in, that package that comes in, is actually a function. So we're gonna add another parentheses set onto it to execute that function. And we're going to tell it what array we want it to parse, which is the process.argv.slice(2).

So I'm gonna copy that and put it in here as the input to that function. And then what comes back from that function call is our actual object that has all of our args in it. So I'm gonna set that equal to args. We need to console.log the args [LAUGH].

>> Kyle Simpson: You'll notice now we're getting an object back. There's an object that has a hello property on it with the world, and then there's another one with c. And you'll notice this one knew it was a number, or it assumed it was a number. Again, there's a bunch of conventions around that sort of thing where if there's a short parameter name and then something looks like a number, it's assumed to be a number instead of a string.

So you don't wanna go reinvent all of those wheels, minimist does that for us. The underscore over here, by the way, that's in this object, this is the overflow if there's anything else on the line that minimist couldn't figure out what to do with. So if I were to do a single hyphen and something like foobar, you'll notice that we have the hyphen and the foobar in the underscore.

Cuz it's like, I don't know what's happening here, that doesn't look like anything I can deal with. So that's sort of the overflow if there's stuff on the line that it hasn't been able to parse according to its conventions, okay? Let's go back to our code for a moment, and let's observe that we can also pass in a configuration to minimist.

So I'm gonna add a second argument here that is an object. And this configuration, among other things, is gonna allow us to control some of the guesses that minimist makes. So minimist might be guessing that we want something to be a boolean, and we want it to be a string, for example, or vice versa.

So first off, what I wanna do is I want to assume that help, in particular, help is always gonna be a boolean. So by saying boolean and then giving an array of parameters that I'm expecting, and you don't need to put any of the dash or dash dash stuff.

You just say, any parameter that's called help, I want you to assume that's always a boolean, even if it comes in with a value or not. And then we might have a different one, and this is gonna lead to where we're going with the exercise. If we specified, say, a file parameter, we want that one to always be treated as a string.

So let's configure that string, that anything in this list is always a string.
>> Kyle Simpson: So if we try this again now, if we run our code, I'm gonna say ./ex1.js, I'm gonna say --help. And I'll try to give it some kind of value, and you'll notice that it still treats it as a boolean.

Because we have overridden the default guessing to tell it no matter how it's specified, I always want it to be a boolean. If it's present, it's true, if it's not present, it's false, okay? And then if we do something like --file, and we give it no value, that would typically be assumed to be a boolean.

But because we've told it to be a string, you'll notice that it comes in as an empty string. So we're overriding some of those defaults, allowing us to very specifically control we know this one should always be treated as a string.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now