Introduction to NPM

If you think about the underlying architecture of writing software, the program is usually comprised of a collection of modules (a module being some code that is grouped together, usually by file). If you have one or more modules that are program agnostic, meaning they can be reused in other programs, you'd create a "package".

This package architecture is what makes the JavaScript ecosystem so powerful. If there's a package you need, odds are it's already been created and is available to download for free. Want to use Lodash? You'd download the **lodash** package. Want to use MomentJS to better manage timestamps in your app? Download the **moment**package. What about React? Yup, there's a **react** package. Now the question becomes, how and from where do we download these packages?

The traditional way is to create a **<script>** tag that links to a CDN where the package is hosted or if you download it locally, the path to that file.

This approach works, but it doesn't scale very well. First, if the CDN servers crash, your app crashes with it. Second, the order of the **<script>** tags matters. If library B is dependent on Library A, but the **<script>** tag to load library B comes before the **<script>** to load library A, things will break. Finally, you have a versioning problem. If jQuery releases a new version, you either need to manually swap out the CDN (assuming there's an updated one), or you'll need to re-download the new version to have it locally. Now for just one package this probably isn't a big deal, but as your application grows and you start having to manually manage 20+ packages, it's going to be a pain.

So let's try to conjure up a solution; here's a list of what we need.

• Make it easier to download packages

• Make it easier to upload packages for others to consume

• Make it easier to switch versions of our packages

• Do it all for free

Luckily for us, there's a company which solved all of our problems.

npm, Inc. is a for-profit, venture-backed company founded in 2014 and was acquired by Github in March of 2020. They host and maintain "npm" (short for Node.js package manager). npm consists of two parts: a registry (for hosting the packages) and a CLI (for accessing and uploading packages). At the time of this writing, the npm registry has over 800,000 packages being installed over 2 billion times a day by over 11 million JavaScript developers, 🤯.

In order to use the npm CLI, you'll need to install it. However, if you already have Node installed, you should already have npm as it comes with Node. If you don't have Node installed, you can download it from here or use a tool like Homebrew.

If Node and npm are installed correctly, you should be able to run the following commands in your terminal to check which versions you have installed.

Now that you have Node and npm installed, the next step is to actually download a package. Before you do that, though, you'll want to initialize your new project with npm. You can do that by running **npm init** inside of your project's directory. This will walk you through some steps for initializing your project. Once finished, you'll notice you have a brand new **package.json** file and an empty **node_modules** directory.

Whenever you install a package, the source code for that package will be put inside of the **node_modules** directory. Then, whenever you import a module into your project that isn't a file path, i.e. **import React from 'react'**, your app will look to **node_modules** for the source.

You can think of your **package.json** file as containing all of the meta information for your project. It contains information like the project's name, author, description, and most important, the list of packages (as well as what versions) that your project depends on as well as how to run your project - here's an example.

A few properties to point out.

These are the packages your application needs to run. Whenever you install a new package, the source for that package will be placed into the **node_modules** directory and the name and version of that package will be added to the **dependencies**property in your **package.json** file.

If **dependencies** are the packages your application needs to run, **devDependencies** are the packages your application needs during development.

The reason it's so important to keep track of your **dependencies** and **devDependencies** is if someone downloads your project and runs **npm install**, npm will download all of the packages inside both **dependencies** and **devDependencies** and place them into the **node_modules** directory. This makes it so when you push your code to Github, instead of having to push up your entire **node_modules** directory, you can instead keep track of your dependencies and install them when needed using **npm install**.

The reason **dependencies** are separate from **devDependencies** is so you can build your app for production. In production, you don't care about the packages needed to develop your app; you only care about the packages needed to run your app.

You can use the **scripts** property to automate tasks. In the example above, we have two, **start** and **build**.

In order to run your script, **cd** into the same directory as the **package.json** file and from the command line run, **npm run [NAME OF SCRIPT]**. In our example, we have our **start** script running **webpack-dev-server --open**. In order to execute that script, from the command line we'd run **npm run start**.

Now that we know all about initializing our project with **npm init**, **node_modules**, and the **package.json** file, the next step is to learn how to actually install a package from the npm registry. To do this, from the command line, run **npm install package-name**.

npm install react

That command will do a few things. It'll put the **react** package inside of our **node_modules** directory as well as add **react** as a property on our **dependencies**object inside our **package.json** file.

To tell npm you're installing a developer dependency (and it should be put it in **devDependencies** instead of **dependencies**), you'll append the **--save-dev** flag.

npm install webpack --save-dev

There wouldn't be over 800,000 packages on the npm registry if it wasn't easy to publish one. All you need to publish a package is an account on npm, a package.json file with **name**, **version**, and **main** (which points to the entry point of your package) properties.

Once you have those things, in your command line run **npm login** to login then **npm publish** to publish your package.

There are more advanced features about publishing that we won't go into in this post, but if you're curious, you can check out their official guide.

Earlier one of our needs was the ability to more efficiently manage the different versions of the packages we were using. The npm CLI helps us out here as well.

Typically each package on the npm registry follows semantic versioning. There are three parts to semantic versioning, major versions, minor versions, and patch versions.

v1.2.3

In the version above, the major version is **1**, the minor version is **2**, and the patch version is **3**.

The idea is if you're a library author and you had a breaking change, you'd increment the major version. If you had a new, non-breaking feature, you'd increment the minor version. For everything else, you'd increment the patch version.

So why is this important? We want to avoid having our app break because we installed the wrong version of a package. npm gives us some tools to prevent this.

If you look at the **dependencies** inside of our **package.json** file again, you'll notice that before each version number, there's a little **^**.

What the **^** does is it instructs npm to install the newest version of the package with the same major version. So for example, if the **prop-types** package released v15.8.0, when we ran **npm install** on our project, we'd get that new version. However, if there was a breaking change and **prop-types** released v16.0.0, only the newest v15.X.X version would be installed and not the breaking v16.0.0 version.

If instead, you wanted to have both the major and minor version match, you'd use **~**.

Now, if **v16.0.0** or **v15.8.0** came out, neither would be installed. However, if **v15.7.3** came out, it would be installed since its the newest version where both the major and minor versions match.

Finally, if you wanted to only download the exact version of what's listed in your **package.json** file, you'd list only the version number.

Now, only v15.7.2 will ever be installed.

If you want to see a few less common options for specifying acceptable ranges, you can check out the Semver Calculator