Now that we know what npm stands for and have a super general idea of what it does and how it fits into web development, we ought to spend a little bit of time looking at the command line, because it’s how we interact with npm.
Guide chapters
Table of Contents
- Who the Heck is This Guide For?
- What the Heck Does “npm” Mean?
- What the Heck is the Command Line? (You are here!)
- What the Heck is Node?
- What the Heck is a Package Manager?
- How the Heck Do You Install npm?
- How the Heck Do You Install npm Packages?
- What the Heck Are npm Commands?
- How the Heck Do You Install an Existing npm Project?
An overview of the command line
The command line is a place we can type (predictably enough) commands to be executed directly by our computer. It’s extremely fast, and allows greater admin permissions than most apps that attempt to handle the command line for you. Need to install something on your system, or perhaps update it? The command line can do that, not to mention uninstall them, too. Heck, even server-side languages can run on the command line, opening up a wide range of tools and development techniques.
It’s for those reasons the command line is considered an indispensable tool for many developers. Even if you’re not a developer, odds are you’ve encountered the command line at some point. Maybe you’ve accessed it when you opened the Terminal app in MacOS. Maybe you’ve used one built directly into your code editor—VS Code and many other code editors come with integrated terminal. Perhaps you’ve even come across third-party terminal apps like iTerm or Hyper.
If you’ve used the terminal, it’s possible that much of your command line usage to this point has simply been typing (or pasting) commands somebody else gave you. That’s fine; that’s often how we get things done.
But let’s take a moment to understand exactly what the command line is, and why it’s so broadly used.
Command line vs. terminal
The “command line” and the “terminal” are technically two different and distinct things, but are often used interchangeably. You may also hear the command line called a “shell” or see it abbreviated as “CLI” which is short for “command line interface.”
Pedantic distinctions aside, the terms are often used to mean pretty much the same thing. So just to keep things as simple as possible, I’ll be using them interchangeably from here on out.
Opening the command line
Whatever you want to call it, you probably know the command line as that scary-looking window, perhaps with a dark background and white (sometimes greenish) text, where you type commands that your computer seems to understand, even if you do not.
Depending on where and how you’re working on the command line, one of the first things you might notice is an inconspicuous dollar sign character, $, that’s displayed on the first line where you’re able to start typing. You may have even seen it in other articles or documentation.
It’s common convention to prefix commands with a $ character—but it’s a confusing convention for sure. That’s because there’s no need to type it. It’s literally not part of the command. Instead, $ signifies a command that’s meant to be run in a terminal.
So here’s the first rule to know about working with the command line: if you find yourself typing or copying an instruction that includes the $ character, know that there is no need to include it in your work; the terminal’s got it covered.
## No need to copy the $
$ npm run buildYou may see something else beginning a line instead of $, like >, _ , or even an arrow. Again, whatever it is, it’s almost certainly not meant to be typed or pasted directly into the command line. Whether or not documentation or other tutorials should include the starting character of a line is an entirely different conversation (one that Chris has discussed at length). Either way, it has the potential to be confusing, so I want to make sure that’s called out.
What does the command line do?
Movies and TV shows often portray a terminal as something fast-typing hackers use in a dark, secluded room. That’s partly just because it makes for good entertainment for folks who probably wouldn’t know a real terminal from the cascading letters in The Matrix. (Nor should they; I couldn’t tell if a surgery portrayed on a TV show is accurate, and am perfectly content leaving that distinction to the professionals.)
But the command line isn’t exactly for writing code. As the name “command line” implies, it’s for writing commands. I suppose you could say that all coding is commands to some extent, so this is admittedly a bit of a blurry line. But generally speaking, code in a terminal is written differently than it is in a code editor. Instead, you use the terminal to boss your computer around with commands you want it to run immediately.
The advantages of the command line
You may wonder why developers like to work in the command line in the first place. You might prefer a nice app, or graphical user interface (GUI for short, sometimes pronounced “gooey”) where you can see all your options and find the best one visually. That’s perfectly fine, and we’ll talk a bit about GUIs in this chapter and provide examples of them.
Many developers feel that way, even if it doesn’t seem like it. But working within the command line brings some advantages that aren’t always easy to replicate in a visual app.
It grants you god-like system privileges
The command line is what computer science-y people refer to as a “privileged environment.” That might sound like it refers to a Yale frat house, but it just means it’s a place where there are very few restrictions on what you are allowed to do; a place without guardrails.
This is where the command line’s daunting reputation comes from—whatever command you type, as far as it’s valid, is executed immediately and, often, irreversibly. It’s capable of interacting with the hidden files your operating system tries to prevent you from editing. You have the power to access anything in the system. You even have the power to interact with similar core files on a remote server—and we all know the adage that great responsibility comes with that kind of power.
It might be helpful to think of the command line like a lazy security guard. It assumes you always know what you’re doing and lets you right through the entrance. That makes it a bit risky, yes, but it also makes it very powerful, and the perfect choice for certain tasks and projects.
It’s super fast
Another advantage the command line has over typical apps is: it’s fast.
This isn’t always the case; the command line’s speed tends to be overstated and depends largely on the task in question. But when it is faster, it can often be many times faster. Plus, the place where the command line really shines tends to be exactly the place where code projects need speed the most, which is downloading and creating files.
As we’ll see in other chapters of this guide, a key part of what npm does is install things on your machine (usually in a folder that’s designated for the project you’re working on). That’s what makes the command line great for working with a package manager (we’ll get to what that means, too) like npm—it downloads and transmits files between computers—generally much, much faster than, say, using a browser to do it.
The command line enables npm to generate tons of files with incredible speed. The ability to run a single command that installs, updates, or deletes those files together in one fell swoop at high speed makes the terminal the fastest, most efficient tool for many jobs.
It does what other languages cannot
One more other reason working in the terminal is so advantageous is that it’s the place where many of the tools you might want to use in your project are already available to you without any additional setup.
But let’s back up a bit.
When you hear the phrase “server-side language,” you might think of PHP, Ruby, or Java. Maybe it’s even newer entries into the space, like Rust or Go. You might even already know that Node belongs on that list, but if not, forgive me for jumping ahead just a bit.
Anyway, when most people think of server-side languages like these, they tend to think of a web server waiting for requests and then responding to them. WordPress, for example, sits idle until it receives a request that fires up PHP. When you send a new tweet, that’s a request on Twitter’s servers that eventually hits a Ruby method in Rails.
Server-side languages are rightly considered more powerful, so to speak, than web languages. HTML, CSS, and JavaScript are wonderful, but they can’t work with a file system, send email, process images, issue system commands, interact with the operating system, or run scheduled tasks; among many, many other things an app or website might need to do. By default, JavaScript in the browser can’t even run unless somebody is actively looking at the web page in their browser.
It’s normal to think of server-side languages as the powerful engine behind more robust apps and software. And, in many cases, that’s accurate. But let’s take a moment to recognize that for the purpose of running code, your machine is a server. Not a web server although (it could be one, but that would be weird and probably unwise). But a server, nonetheless.
You can install and run any of the server-side languages we’ve mentioned, and perhaps you’ve already even done so at some point (or at least tried to). You might have installed PHP so you can run WordPress (though these days there are much nicer ways to do it), or you may have installed Ruby so that you could follow some tutorials about Rails, just as examples.
Or, maybe not. Maybe you’ve never installed a whole dang programming language before. Either way, just know that these languages run on a server rather than a web browser—and for that purpose, your machine is a server.
Beyond that, many of the tools you might want to use with your development workflow—things like Sass for compiling CSS—actually run on server-side languages. So using the command line puts you in the place where all the most powerful tools are readily available.
Using an app instead of the command line
We briefly touched on GUIs earlier in this article. It’s worth noting that some command line tasks have corresponding GUIs that make working with the command line more visual and programmatic.
Good examples include GitHub Desktop (for managing code repositories) and CodeKit (for processing, bundling and compiling assets), though the Source Control tab in VS Code also qualifies. Even though GUIs like these are generally focused on specific duties, they let you get things done through a nice visual user interface, in an actual app window that’s outside of the terminal window.
A GUI is lovely to have as an option, and even though I’ve become quite comfortable working on the command line over the years, I still wish there were more GUIs to do the things the command line makes possible—both for my own convenience and to lower the barrier to entry for new developers.
I believe the reason there aren’t more such apps, however, is because of speed. It’s much quicker and easier to build a command line interface (CLI) than it is to put together a full-fledged app, often by orders of magnitude. So if we want nice things today, the command line is often the place we need to go for them.
What’s next
We just spent some time getting acquainted with the command line. Even though the command line is not specific to npm, it’s core to working with npm. It’s the interface from which we tell the system what to do, granting us incredible powers at the system or server level to complete tasks in large swaths at breakneck speeds. As a package manager, npm is in the business of installing, updating, and deleting files (among other things) for a web project. The command line is how we communicate with npm to do all of that.
Next up, we’re going to break down what npm is a little more by focusing on the first letter in the abbreviation: “n” for Node. What the heck is that and why is it in the name? That’s where we turn our focus next.
