npm – CSS-Tricks

A Complete Beginner’s Guide to npm

Josh Collinsworth — Thu, 20 Jan 2022 15:07:32 +0000

I remember vividly a period early in my coding career when I began to feel that things were changing away from what I knew, and headed towards a more complex set of tools and practices, anchored in the command line and something called npm.

This is the first part of a beginner’s guide where we cover the broad topic of Node Package Manager, or npm. We often take those three little letters—npm—for granted as we type them into the command line, but npm is part of a much larger ecosystem that can often be intimidating or confusing to anyone jumping in for the first time. This guide will help de-mystify that ecosystem and help you not only understand what npm is and does, but ultimately feel comfortable working with it.

Guide chapters

Modern “back-of-the-front-end” development—which npm is a part of—seems complex because it’s one name for lots of interconnected tools. When you add in the fact that the front-end world seems to move much more quickly than it actually does, producing a feeling that you will be left behind for not jumping on the newest thing right away, everything about it can seem unapproachable.

That’s why we’re starting this guide—to make the technology more accessible for you to use in your own work.

Who the heck is this guide for?

In my own personal development learning journey, I would read guides about technologies that excited me, then get to a part that said “just npm install” this or that, and I’d heave yet another disappointed sigh and give up on using whatever that cool-looking thing was. Or, on more adventurous days, I might copy the command, but then inevitably end up either at another step I didn’t understand (“just,” they always said, “do [some thing I had no idea about]”), or get an error message the guide didn’t explain that stops me in my tracks.

Whatever npm was—whatever those commands did and wherever you were supposed to type them—nobody had ever taken the time to explain it to me. And the more I read guides written by people who took that knowledge for granted, the more I felt isolated.

If any of that sounds familiar: this series is for you.

You most likely fall well within the group that’s been described in recent years as “front-of-the-front-end.” Like me, you probably know your stuff when it comes to HTML and CSS. Maybe you also know some JavaScript, either “vanilla” JavaScript, or by way of jQuery. Either way is fine, both for the purposes of this article and in general.

Maybe you’ve even tried out a framework like React or Vue, but you mostly just copied and pasted some stuff to get your project up and running, and weren’t exactly sure what that stuff actually did.

This post is for you if you sense The Great Divide between the more traditional and “modern” definitions of front-end development—and if you worry that you might be hurting your career if you don’t bridge that chasm.
This post is for you if you aren’t really sure what all the fuss about terminals and command lines is about, and you’d much prefer to just never touch one at all.
This post is for you if you wonder why other developers seem to love making things so damn complicated, and what the point of all that command line junk is in the first place, when you could just write plain, simple HTML, CSS and JavaScript instead.
This post is for you if you feel left out. If you sense there’s some thing, some really big thing, that nobody’s ever really bothered explaining to you, and you’re worried you’re the only one who doesn’t get it.

Know this, my fellow front-end developer: you are not alone. You are far from it. You are exactly where I was not so long ago, and the unsettled memory of that place is still fresh in my mind.

Let me try to answer the questions you probably have—the same ones that I had—in the way I wish somebody would have for me, before I even knew how to ask them.

What is covered in this guide

This guide is a series of articles. That’s not because this stuff is extremely difficult to understand in and of itself; it’s because there are many parts to it, and each one bears explanation on its own. This is wide territory with a number of rabbit holes to explore. Focusing on one solid step at a time allows us to spend time on making things clear and understandable. The goal isn’t to cover everything, but I do want to be more thorough than quick.

We’ll start by talking about the current lay of the land; what npm is, a bit about where it came from, and how we got here. From there, we’ll cover what Node itself is, followed by what package managers are in general, before actually working with npm. We’ll finish by installing Node and npm (if they’re not already), initializing a project to get an idea of how it works, and finally, installing a real-life npm project from GitHub with all its packages and commands.

Some (or all) of that may sound very intimidating right now, but don’t worry. That’s why we’re spending the length of an entire guide together.

What to know before we begin

I’ll do my best to assume as little as possible about you, beyond that you are a web developer who generally knows how to build a website with HTML and CSS. You won’t need to know much about JavaScript or write any for the purposes of following this guide, but it will definitely help if you have at least a foundational understanding of what JavaScript is and how it works.

JSON is the only other bit it might be helpful to know before getting started. If you’re unfamiliar with JSON, it might be worth glancing over this guide to JSON, or at least having it ready for when we do get to that part.

Beyond that, I may reference specific tools, projects, and frameworks like Bootstrap, React, Vue and SvelteKit, but I won’t assume you have any any hands-on experience with them whatsoever, nor will I assume that you’ve ever used npm or the command line before.

Ready to get started? Let’s begin by clarifying what we mean by “npm,” such as what it stands for and how it fits into modern web development.

Chapter 2 →

A Complete Beginner’s Guide to npm originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What the Heck Does “npm” Mean?

Josh Collinsworth — Thu, 20 Jan 2022 15:04:15 +0000

One of the things that makes this new, tooling-heavy era of front-end development so seemingly hard to understand at first is that, while we often call things by a singular name, they tend to be actually comprised of several different interconnected pieces. The same is true for npm and the ecosystem around it.

For example: Think of how we casually refer to “the internet,” even though the web itself is not a single, unified thing, but a collection of protocols, DNS, servers, browsers, networks, requests and responses, plus lots of other things assembled over years of iterations. For that matter, even the browser itself is one machine with many parts.

Guide chapters

npm is a collection of technologies

In that same way, what we generally think of as “npm” (yes, all lowercase) and “back-of-the-front-end” in particular is a single name for a collection of many different individual technologies and systems; a sort of Rube Goldberg machine to generate browser-friendly code.

I mentioned the command line already; that’s a big part of the ecosystem because it’s how we interact with it. But more on that in the next chapter.

And then there’s npm, which is in a category known as “package management” software. We’ll cover that as well. In fact, you’ll likely see me refer to npm as a package manager throughout this guide.

And finally, there’s Node itself, which is so tricky to explain succinctly I often describe it by paraphrasing Douglas Adams: it’s a programming language that’s almost—but not quite—entirely like JavaScript.

npm manages project tools

To further muddy the waters, many projects where you type npm install into the command line might come with pre-installed tools to help you do a wide variety of things in your project, like process your code (e.g., turn Sass code into CSS). There are many all-in-one, preconfigured projects out there just waiting for you to install them and get started (Create React App, Next, Nuxt, and SvelteKit, to name a few). This is convenient when done well, of course, but it’s also added complexity—meaning many more names we need to add to our list of back-of-the-front-end things.

This list often includes tools like Babel (for compiling JavaScript), Sass (for compiling CSS), webpack (for asset bundling), Vite (for development servers and other tooling), PostCSS (for transforming one syntax into another); Autoprefixer (which can be a PostCSS plugin for CSS vendor prefixes); TypeScript (for additional JavaScript syntax); ESlint (for checking code quality); Prettier (for formatting code), and testing libraries like Jest or Cypress.

npm is like a library building with floors of book collections that are organized, making things easier to find and manage. (Photo: Johannes Mändle on Unsplash)

All those things (and more) fall into this broad, general category of tools that often come with npm-installed projects—or that can be installed and used via npm—but are not actually part of npm itself. They’re just examples of modern tools that help us do nice things with our code, and I mention them here only because it’s worth noting the distinction, to get a sense of where the boundaries lie in this large, new world.

And by the way, if you didn’t know what most (or any) of those tools mentioned above are, that’s ok. Maybe you haven’t come across them yet, or maybe you’ve worked on a project that had them installed without knowing them by name. Either way, all of this is merely for additional context.

Let’s break here

If you’re already feeling a bit overwhelmed at this point: don’t sweat it. The key thing I want you to walk away with after reading this specific chapter is that what we think of as “npm” (or maybe more casually as “all that command line, back-end-y stuff”) is not really one thing, but a collection of things that work together to make development easier for us.

And yes: while all that complication seems intimidating up-front, it does actually make things better. I promise.

While front-end seems to move very quickly, no, you have not been left behind. You may just have a bit of continuing education to get caught up on.

← Chapter 1

Chapter 3 →

What the Heck Does “npm” Mean? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What the Heck is the Command Line?

Josh Collinsworth — Thu, 20 Jan 2022 15:04:09 +0000

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

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.

By default, a terminal window probably looks something like this, though its appearance can vary.

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 build

You 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 probably don’t think of your machine as a server—nor should you. But it can run server-side programming languages.

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.

CodeKit can execute a command to check code formatting with tools like ESLint without directly using the command line.

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.

← Chapter 2

Chapter 4 →

What the Heck is the Command Line? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What the Heck is Node?

Josh Collinsworth — Thu, 20 Jan 2022 15:04:03 +0000

(This is a sponsored post.)

Here’s what you need to know about Node.js (or simply Node) and how it relates to npm right off the bat:

Node is JavaScript, but as a server-side language.
This is possible because of V8, Chromium’s JavaScript engine, which can run on its own, outside the confines of the browser.
Node and browser-based JavaScript can be very different, and have different capabilities, though both are JavaScript at their core.
You don’t need to know Node to use npm.

As you may know by now, npm stands for Node Package Manager (even if the official npm website displays amusing alternative names in its header on each page load, like “Ninja Pumpkin Mutants”).

The key thing to understand right away is this: “Node” and “Package Manager” are the two big, distinct pieces that combine to make npm.

We’ll cover what a package manager is and why you might consider using one when we get to the next chapter in this npm guide. For now, though, let’s focus on understanding what Node is, as it’s is a key part to understanding modern web development.

Guide chapters

Node is JavaScript, but without all the browser

You likely know JavaScript primarily as a language that runs in the browser, similar to HTML and CSS. Yes, each of these languages has abstractions and supersets (like HAML for HTML, Sass for CSS, and TypeScript for JavaScript, as examples), as well as compilers and transpilers and all kinds of things that transform them into this shape or that. But ultimately, what these tools generate is vanilla (i.e., pure) code in the correct syntax, as if the abstractions were never used, to run in the browser and in the browser alone.

That’s the thing that took me the longest time to understand, and which, honestly, might be an even bigger missed memo than the whole npm thing. JavaScript doesn’t need a browser anymore in order to run. So, you’ll sometimes see me refer to Node JavaScript when distinguishing between it and “browser-based” JavaScript.

Server-side vs. client-side languages

At this point, I feel it’s worth taking a moment to explore the distinction between client-side languages (HTML, CSS, JavaScript), and server-side languages (basically all the rest of them). I won’t assume you have any experience with server-side languages, like PHP, Ruby, or Python, but if the concept of server-side languages is entirely new to you, it may be worth reading up on what they are. (To summarize: they’re code languages that run purely on a server instead of the browser, and generally have much broader and more powerful capabilities.)

This is relevant because several years ago, circa 2009, there were some very smart people who really liked JavaScript. In particular, they liked how fast JavaScript is (especially compared to the dominant server-side languages at the time, most notably, PHP and Ruby), and they wanted to have JavaScript everywhere, not just in a browser.

Ryan Dahl is the most prominent figure among them, and is credited with the invention of Node (and more recently, Deno, which is an anagram of Node). That’s a fun thing to know, but otherwise not strictly relevant to this topic.

How Node works

What is relevant, though, is that Node is essentially JavaScript as a server-side language that runs outside of the browser.

How is that possible? Under the hood, each browser has its own individual JavaScript engine. This is the part of the browser that actually runs JavaScript. Yes, that’s apparently a separate piece of the browser and not part of the same bits that do the HTML and CSS—which I guess makes sense when you think about the fact that we have literal APIs between the document and JavaScript. Heck, even the concept of a DOM makes more sense when you think of the department that handles JavaScript as a makeshift office down the hall from the HTML department.

The JavaScript engine in Chromium-based browsers is called V8, presumably after a specific kind of car engine (not the “vegetable drink” made mostly of tomato juice). V8 is by far the most popular JavaScript engine. Thanks to ECMAScript standardization efforts over approximately the last 15 years, there aren’t really any major differences between JavaScript engines anymore as far as browsers go. The engine used in Chrome is a lot like the engine that runs in Firefox, which is a lot like Safari, and so on. V8’s popularity these days has less to do with its distinctions, and more to do with Chrome’s self-sustaining ubiquity.

(Side note: Firefox’s JavaScript engine is named SpiderMonkey. That’s not particularly relevant, but it is further proof that Firefox is the coolest.)

Why does this matter? Well, it turns out, you can take the JavaScript engine out of a browser, and with some modification, run it on its own—kind of like if you decided to pull the stereo out of a car, tinker a bit, and make it into a stereo system for your home instead. V8 (and, presumably, a car’s stereo) can function perfectly fine as a standalone unit in any environment.

In other words: V8 makes it possible to run JavaScript anywhere. That’s why we have “Node” JavaScript and “browser-based” JavaScript.

Node is almost (but not exactly) JavaScript

To recap: JavaScript is a server-side language now! It’s called Node, and it could mean you don’t even need to learn anything about other server-side languages. We are front-end developers, and we have super-powers now.

Having said all this, however, Node and the JavaScript you’re used to running in the browser are both similar and very different from each other.

At the risk of veering too far into the weeds here: while both are JavaScript at their core, and while the language and syntax is the same, many staples of JavaScript in the browser (like the window or document, and even the oft-taken-for-granted alert) are not present in a purely server-side Node environment. There is no window, of course, when the language is just running on its own, and not in a browser. New Node JavaScript developers are often surprised to learn that even fetch is actually a browser API, not “pure” JavaScript.

Fear not, however. console.log is still your best friend, and there are many new, environment-specific features of Node JavaScript that differ from the browser’s implementation of JavaScript, such as the process object, which contains all the details about any processes that are currently running.

Node and its ecosystem have often, out of necessity, grown in a very different direction than browser-based JavaScript over the years. (As an obvious example: the syntax for imports between the two has been different for years, and only now is beginning to merge together again. We’ll talk about that a little more in the final chapter.)

Node long held the privilege of being able to move much faster than browsers when it comes to gaining new features, and has had its own set of concerns to deal with as well. It began to power server-side apps the same way Ruby and PHP had been doing for years, even while browsers were still trying to coalesce on standards. This has resulted in Node JavaScript and browser-based JavaScript becoming more like cousins than clones.

Here’s what I think is a fair analogy to explain the differences between the two JavaScript cousins: consider two similar musical instruments, say an upright bass and a modern electric bass guitar. Both instruments are tuned the same, and play the same notes; if you know one, in many ways, you kind of know the other. But while you’ll find it much easier to learn one after you’ve learned the other, playing the new one will be very different from what you’re used to.

The same, but different (Photos: Wikimedia Commons, Unplash)

Similarly, while one developer might write one type of JavaScript and a second developer writes in another type of JavaScript, their jobs are unlikely to look the same.

Node is JavaScript, with the capabilities of other server-side languages mentioned before—things like reading from and writing to the file system, access to system-level APIs, email, the ability to listen for and respond to requests, scheduled tasks… the list goes on.

I won’t say more on that here, but just know that while both are JavaScript at the end of the day, they run in different environments and are each capable of doing some things the other can’t. Even if you’ve written browser-based JavaScript before, Node will still likely feel a bit foreign to you beyond the foundational syntax, and will often be used in very different ways.

Running Node locally

As is generally the case with server-side languages, you do need to install Node before you can use it.

Node is commonly installed alongside npm, together as one, since the package manager part needs Node, and the Node part is more useful with a package manager. (You could say they’re a package deal. No, I will not apologize for that joke. I am a dad, after all.)

I’d like to stress at this point that you don’t need to know anything about Node to use npm. So, even though I’m about to cover some Node examples here, please consider this entire section something that’s nice to know, but inessential to that end. I feel it’s still useful to get a slightly better idea of how Node works, just for the sake of painting a more complete picture.

We will cover how to install Node and npm in an upcoming chapter of this guide. So, if you don’t have it installed already, you can either just glance over this part, or come back here when you do have it ready. Either way, this won’t be crucial for following along with this npm guide.

If you would like to try it out, you can create a new test.js file and put some generic JavaScript in it. Something contrived like the following code that logs some content to the console should do the trick:

console.log('Look, ma, Node hands!')

const oneThroughFive = [1, 2, 3, 4, 5]

oneThroughFive.forEach(number => {
  console.log(number)
})

Let’s say you save that code, then open the command line in a terminal window, navigate to where the file is (using cd, or “change directory”), and run node test.js to get the following output:

Look, ma, Node hands!
1
2
3
4
5

You can also enter node by itself (no filename afterwards) to open an interactive terminal where you can run arbitrary Node JavaScript. If you’ve ever popped open the console in your browser’s DevTools to type out some code, that’s exactly what this is, just on the command line with Node instead.

Try it out if you’d like to, assuming you do have Node installed. But again, this is all just for illustration and not required for using npm.

What’s next

Everything we covered in this chapter is nifty and hopefully helps to show you (however simply) the way Node works. Remember, while we didn’t cover any specific example of it, Node is capable of doing anything a server-side language can do. It’s hopefully not too hard to picture how running some JavaScript to do virtually anything you can think of on the system level or even on a remote server is very appealing and advantageous.

The concept of Node started as a way to run JavaScript outside of the browser. As such, we have Node-based packages of scripts that are used to help us with front-end development. So how do we install those packages and make sure they’re not only updated but that they can be uninstalled? That’s contained in the last two letters in the npm abbreviation: package manager.

In other words, npm is a tool that manages packages written in Node JavaScript. What exactly is a package manager and how does npm qualify as one? That’s up next in our npm guide.

← Chapter 3

Chapter 5 →

What the Heck is Node? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

What the Heck is a Package Manager?

Josh Collinsworth — Thu, 20 Jan 2022 15:03:59 +0000

If you’re keeping score, so far in this npm guide we’ve developed a general understanding of what npm is—notably, that it stands for Node Package Manager. In the process, we’ve discussed the importance of the command line and how it’s used with npm.

We also looked specifically at the “n” in npm—Node—and learned that Node is a lot like the JavaScript code we write to run on websites in a browser. In fact, Node is JavaScript; it just runs outside of the browser, and is capable of doing different things than its browser-based counterpart.

Guide chapters

What we mean by “package”

Now let’s turn our attention to the last two letters in npm, namely the “package manager” part. In order to fully understand what npm is, we need to know what a package manager is. So it naturally follows that in order to understand that, we need to understand what the heck a “package” is.

“Package” is a catch-all term for any external code files that you pull into a project and use in some way. Perhaps you’ve used jQuery, Bootstrap, or Axios on a project in the past. Those are common examples of packages.

We call these “packages” because they’re “packaged up” and ready to be used. Some languages call them by other names (Ruby calls them “gems” for example), but the concept is the same. At the risk of oversimplifying, a package is code that you didn’t write but got from some public source to use in your project. You know, third-party code.

Or, if you prefer musical parodies for your mnemonic devices:

🎵 When there’s code that you choose
🎵 That’s not yours, but you use
🎵 That’s a package
🎵 When it’s stuff you install
🎵 That you import and call,
🎵 That’s a package

Packages are also often also referred to as “dependencies,” because the code you write depends on them being present. Code written using jQuery’s $ won’t work right if jQuery itself isn’t already loaded, for instance. (For this reason, package managers are also sometimes called “dependency managers.”)

Packages can be big or small in terms of how much code they contain. A package might do something huge that changes how you write your whole project (like an entire framework), or it might do something very small and focused that you sprinkle in only where needed (like a widget, or a helper for a specific task).

Using packages without a package manager

Most likely, if you have used a package in the past, you’ve simply applied it with a script tag in the HTML that pulls from an external URL (ideally from a CDN). Here’s how you might include jQuery in the HTML of your site:

Another approach is to download a copy of the package, add it to your project’s files, and link to it locally, like this:

What package managers solve

These two approaches have worked well for years. It’s simple. It’s clean. It generally lets you “set it and forget it” as far as the package goes. So why would you need something else?

You can probably imagine how owning a car might seem unappealing to somebody who has ready access to convenient transit, or who has no need for long-distance travel. (This will tie back into the package manager talk, I promise. Stick with me.)

If you have easy access to convenient and efficient mass transit, then paying a large price for a massive machine that you have to store somewhere, regularly clean, maintain, and fill with costly fuel probably won’t carry much upside from your perspective. In that specific case, the benefits are negligible; the costs are comparatively overwhelming. Someone in that hypothetical position might even wonder why anybody wants a car at all!

I bring up this analogy because learning about a new technology can be very hard when it solves a problem you don’t have, in very much the same way that buying a car might fail to solve transportation you already have. It might seem like a massive, needless expenditure.

What a package manager solves, then, is more a matter of scaling and handling concerns. Simply linking to a package in a script tag works well, as long as:

the number of projects you have is manageable;
the number of people working on the projects is manageable;
the number of updates that need to be made to the packages are manageable; and, most crucially,
every package used in your projects is client-side (browser) JavaScript or CSS.

That last one is the doozy, because there’s a plethora of tooling you can’t ever use if you only run things in the browser (more on that in a moment).

If you do check all of those boxes, you might not ever outgrow this approach. Your development approach might just look like this:

But even in that case, when you have multiple

Running the script spits out the UA and what features you want.

UA detected: chrome/56.0.0
Features requested: default

Change request parameters

There are a bunch of options to customize the request which you put into the script source.

Features

List of browser features to polyfill. Accepts a comma-separated list of feature names. Available feature names are shown on the Browsers and Features page.

In Safari 10 the script now says something like this:

Features requested: fetch

- setImmediate, License: CC0 (required by "Promise", "fetch")
- fetch

If a feature like fetch depends on another feature like Promise, Polyfill.io automatically adds it.

Flags

always – Polyfill should be included regardless of whether it is required by the user-agent making the request.
gated – If the polyfill is included in the bundle, it will be accompanied by a feature detect, which will only execute the polyfill if the native API is not present.

Callback

Name of a function to call after the polyfills are loaded. It is simply a way of triggering your own code when the polyfills have loaded, intended to allow the polyfill service to be more easily loaded asynchronously with async and defer attributes.

The Problem

As good as all this sounds, it is still not perfect.

Modern browsers do not have to load ES5 now, but instead have to make a server roundtrip (an HTTP Request) to check if polyfills are needed.

This bugged me so much that I worked on a little project to help.

An Even Better Way

Set up dynamic polyfill

The npm package I created is called dynamic-polyfill. It checks whether the feature is natively supported or not before making any server request.

The setup looks like this:

import polyfill from 'dynamic-polyfill'

polyfill({
    fills: 'fetch, Promise',
    options: 'gated', // default: null
    minify: false,  // default: true
    afterFill() {
        main()
    }
})

function main() {
    // app code here
}

That will execute essentially like this, in plain language:

Do [window.fetch, window.Promise] exist?

If they do, run the afterFill() callback.

If they do not, create a