An Intro to Dependencies and Package Managers (NodeJS style)
Tags: codenewbie, wecoded, javascript, beginners
Published: 2020-01-20 00:35:53

In this post, I'm going to give a brief intro to package managers, dependencies, and semantic versioning.

## What are dependencies?

Any given development project will likely have numerous **dependencies**. "Dependency" is just a word to denote a framework or a library that someone else has written to make your life easier. Thanks, dependency authors! Dependencies allow us to write less code and spend less time figuring out logic from scratch. Sometimes you will hear dependencies referred to as **packages**.

### Dependency hell

A given dependency itself could have a bunch of its own dependencies. For example, say I have a project with ExpressJS as its only first-level dependency. The `package-lock.json` file, which keeps track of the dependencies of a given package, is **375 lines long**. My `node_modules` file, which is where all those sublevel dependencies are installed, has 49 modules added to it. This is just on account of installing *one* dependency.

Imagine if you had to install Express, plus all of its dependencies, and then all the dependencies of those dependencies... No thanks. Dependency hell is what that is!

Enter package managers.
## Package managers
Package managers are tools (written and maintained by developers) that automate the task of installing and updating the dependencies of our project.

When we use a package manager (like npm or yarn) to install a package in our NodeJS project, the given package is added to the `dependencies` of our `package.json` file -- and all of that dependency's dependencies are also installed. You can find all of secondary dependencies in your `node_modules` folder, as well as in the `package-lock.json` or `yarn.lock` file, depending on which package manager you're using.

(Package managers pull dependencies from **package registries**. [npm](https://www.npmjs.com/) has its own registry that is actually the default registry for yarn as well. [Github](https://github.blog/2019-05-10-introducing-github-package-registry/) released their own registry in mid-2019.)

### Package versions and team collaboration

If we're using Github to work on a team project, conventionally, we keep the `node_modules` directory in our `.gitignore` file. This means that anyone who wants to work on the project must run `npm install` or `yarn` after cloning from Github to install the relevant dependencies.

Here, some potential problems come into play with *versioning*. Any given package has a version number that looks something like this: **1.2.3**. Each part of that number represents the *major*, *minor*, and *patch* version of a package, respectively. 

**Semantic versioning** is the name of an agreed-upon system that helps developers decide what kind of new version they'll be implementing with a given change: i.e. will it be a major, minor, or patch release? ([Semver.org](https://semver.org/) has some detailed info on how developers should distinguish between the versions, and a thorough explanation of semantic versioning theory.) 

Additionally: in your `package.json` file, the version number by a given dependency can be preceded by a carat (`^`) or a tilde (`~`). `~1.2.3` means to install only the newest patch version of a package, so up to `1.2.9`. `^1.2.3` means to install the newest minor or patch version, so up to `1.9.9`. A normal install will automatically add a carat to this version. You can remove this carat to indicate that the install should exclusively download the curently listed version.

So ideally, developers working on a project will be using the same version of a package, because, depending on whether it's a major, minor, or patch update, certain parts of the dependencies could behave in new ways that might break some code.

## npm & yarn

For a while, npm was the de facto package manager for NodeJS projects, and it's still many developers' go-to as well as the default for Node. However, prior to 2016, users were having issues maintaining consistent semantic versioning across teams. 

In 2016, Facebook released yarn, which introduced a `yarn.lock` file. This promised to solve the issue of different developers installing different versions of a package in the same project, leading to bugs. npm soon followed with its own lock file, `package-lock.json`.

(There is still some controversy and confusion around how lock files do and should work, but that's beyond the scope of this article. [This article](https://dev.to/saurabhdaware/but-what-the-hell-is-package-lock-json-b04) is a good start for learning more.) 

Leading up to 2016, npm dealt with a [few major issues](https://www.ryadel.com/en/yarn-vs-npm-pnpm-2019/), and if you had asked me in 2016 which package manager I preferred, I would have probably said yarn. Since then, however, it seems like npm has made major upgrades to catch up to yarn and make up for the issues it created in the past. 

And while npm and yarn appear to be the main players out there for JavaScript package management, they're not the only options. [pnpm](https://pnpm.js.org/) is a newer package manager. If you are developing multiple projects that all use the same version of a particular package, npm and yarn would save the whole package onto your disk for each project. pnpm saves room on your development drive by only saving a package once and using a "hard link" to refer to it in whatever project's `node_modules` file it needs to be in. Check out [this blog](https://medium.com/pnpm/flat-node-modules-is-not-the-only-way-d2e40f7296a3) for more info about how that works.