Finished section for peer deps, lock file

content/blog/how-to-use-npm/index.md

@@ -51,11 +51,11 @@ When it comes to install options there are two:
 
 2) Current
 
-The "LTS" release stands for "long-term release" is considered the most "stable" release, and is recommended for production usage. This is because LTS releases will recieve critical bug fixes and improvements even after a new version comes along. LTS releases often see years of support.
+The "LTS" release stands for "long-term release" is considered the most "stable" release, and is recommended for production usage. This is because LTS releases will receive critical bug fixes and improvements even after a new version comes along. LTS releases often see years of support.
 
 The "current" release, on the other hand, usually sees new features of JavaScript implemented that may not be present in the LTS release. This is often used to experiment and tests new features and functionality before the next LTS release.
 
-NodeJS swiches back and forth between LTS and non-LTS stable releases. For example, Node 12 and 14 were LTS releases, but Node 13 and 15 were not. You can [read more about their release cycle on their website](https://nodejs.org/en/about/releases/)
+NodeJS switches back and forth between LTS and non-LTS stable releases. For example, Node 12 and 14 were LTS releases, but Node 13 and 15 were not. You can [read more about their release cycle on their website](https://nodejs.org/en/about/releases/)
 
 ### Installing Node {#installing-node}
 
@@ -489,7 +489,56 @@ If you include `prettier` and other tools you use to develop the library, it blo
 
 #### Peer Dependencies {#peer-deps}
 
+While dependencies are incredibly useful, if you're using a framework like React, having every dependency in your project install a separate version of React would potentially cause issues. Each dep would have a different version, which may act differently, and your `node_modules` would be bloated.
 
+As such, the concept of `peerDependencies` is to allow client projects to have a single version of a dependency installed that is shared other deps. For example, a library built using JSX might have a `package.json` that looks like this:
+
+```json
+{
+  "dependencies": {
+    "classnames": "^2.1.3"
+  },
+  "peerDependencies": {
+    "react": "^17.0.2"
+  }
+}
+```
+
+This would allow you to have `react` installed on your project and able to share the dependency with anything that requests the peer dep.
+
+It's worth noting in that in `npm 6`, you used to have to install these yourselves. However, `npm 7` made the change such that peer deps are installed automatically. If you see an error from a package saying that your peer dep doesn't match, find the project and make a pull request to add the correct versions of the peer deps. These warnings were not significant with `npm 6`, but with `npm 7`, these matter substantially more.
+
+### Ignoring `node_modules ` {#gitignore}
+
+Once you have your packages installed (either by using `yarn` or `npm`), **it's important that you _do not commit_ your `node_modules` folder** to your code hosting. By commiting `node_modules`, you:
+
+- Bloat the size of your repository codebase
+- Slow down cloning of your project
+- Making it difficult/impossible to do analytics on the code you're using
+- Remove the potential to install security updates with semver ranges in your package.json
+- Break CI/CD systems that plan on running `npm i`
+
+To avoid these problems (and more), be sure to exclude your `node_modules` folder from being tracked in Git. To do this, create a file called `.gitignore`. Then, place the following inside:
+
+```
+node_modules/
+```
+
+Worried that your dependencies might not resolve the same version on systems like CI where having replicable stable dependency installs matter a lot? That's where lock files comes into play
+
+### Lock Files {#package-lock}
+
+Once you run `npm i` on a project with dependencies, you'll notice a new file in your root folder: `package-lock.json`. This file is called your **"lockfile"**. **This file is auto-generated by `npm` and should not be manually modified.** 
+
+> If you're using `yarn`, you'll notice instead this file is called `yarn.lock`. It serves the same purpose as `package-lock.json` and should be treated similarly
+
+While your `package.json` describes which versions you'd _prefer_ to be installed, your lockfile nails down exactly which version of the dependency (and sub dependencies) were resolved and installed when it came time to install your packages. This allows you to use commands like `npm ci` to install directly from this lockfile and install the exact same version of packages you had installed previously.
+
+This can be incredibly helpful for debugging package resolution issues as well as making sure your CI/CD pipeline installs the correct versions of deps. 
+
+While it's imperative not to track your `node_modules` folder, you **want to commit your `package-lock` file in your git repo**. This ensures that things like CI pipelines are able to run the same versions of dependencies you're utilizing on your local machine.
+
+> Something to keep in mind is that different major versions of `npm` use slightly differently formatted lock files. If part of your team is using `npm 6` and the other part uses `npm 7`, you'll find that each team replaces the lockfile every single time `npm i` is installed. To avoid this, make sure your team is using the same major version of `npm`.
 
 ### Scripts {#npm-scripts}
 
@@ -521,8 +570,5 @@ You're not limited to a single command, either. Most projects will have "scripts
 }
 ```
 
-### `package-lock.json` {#package-lock}
+## Conclusion
 
-
-
-### Ignoring `node_modules ` {#gitignore}