Welcome

Setting up our development environment

Introduction

Setting Up Our Project

What are Dependencies?

Installing Scroller's Dependencies

Initializing Git and GitHub

Initialize

Scroller schema

Implementing Scroller

Setting up Storybook

Implement

Setting up ESBuild

JS Modules

Building Multiple JS Modules

Deploying to NPM

Deploy

Typescript

Jest

ESLint

Lint-staged

Maintain

Summary

esbuild

react

In this course, we'll cover what it takes to write, maintain, and publish a React library from scratch. 
In the 2020 State of JS survey, an annual survey conducted of the frontend JavaScript community, React came in as the most used framework for frontend development. Because React is so popular, building libraries in it can open you up to a wide range of users, contributors, and possibilities!

## Why this course

Building a library is so much more than just the code. 
We need to know the ins and outs of versioning, deploying, building, documenting, dependency management, module types, tooling, and more. 
This is a daunting task for just one tutorial to cover. Creating React Libraries from Scratch will teach you everything you need to know to succeed in creating a library.

Don't worry if you're not a React wizard. This course is designed for beginner/intermediate developers who have never deployed a library before and have minimal React experience. However, you should be familiar with JavaScript.

## Course Topics
 
Throughout Creating React Libraries from Scratch we'll develop a React Hook called Scroller that will provide a utility for scrolling around web pages—taking advantage of window.scrollTo. 
We'll start in module 1 with an empty directory; adding documentation files, installing dependencies, and setting up GitHub. Right away, you'll have a project that could be deployable as a fully functional library!
In module 2 we'll implement scroller while taking advantage of Storybook to visually test our code. By module 3 Scroller will be deployed to npm in multiple JavaScript module formats.
Finally, in module 4, we'll look at different tools and techniques in software development to maintain a library. This includes linting, unit tests, TypeScript, and Lint-Staged!
By the end of this course, you'll be able to run _npm install scroller_, and take advantage of React code __you__ wrote in future projects.

Creating React Libraries from Scratch will dive into:
- initializing a new npm package
- maintaining code quality
- publishing to npm
- keeping contributors on track
- exposing modules that work in NodeJS and the Web
- unit-testing
- Storybook for demoing components
- exposing typing using TypeScript
- and more!

In this course we'll cover what it takes to maintain, write, and publish a React library from scratch.

Creating React Libraries from Scratch

Creating a React library from `yarn init` to deployed on npm

The different types of JavaScript dependency types and versioning

Setting up documentation for contributers and consumers

Keeping up with code quality while multiple people work on a project

The end goal of writing a library is having an application consume our code. In other words, our library would become a dependency of a project.
In the same way as projects can depend on our library, our library can also have its own dependencies.

---
title: What are Dependencies?
description: Introduction to project dependencies, devDependencies, and peerDependencies.
slug: what-are-dependencies
privateVideoUrl: https://fullstack.wistia.com/medias/q2kfxknaa7
isPublicLesson: false
useMdx: true
---

import { Quiz } from "~/../components/quiz";
import { Table } from "~/../components/table";

The end goal of writing a library is having an application consume our code. In other words, our library would become a dependency of a project.
In the same way as projects can depend on our library, our library can also have its own dependencies.

There are three types of dependencies:

1.  Dependencies we rely on _(dependencies)_
2.  Dependencies we only need for development _(devDependencies)_
3.  Dependencies we expect our users to provide _(peerDependencies)_

## How package.json defines dependencies

Our `package.json` file defines the three types of dependencies. Each dependency has a name to a corresponding version.
We can use every type of dependency, or none of them at all. There is no rule on the number of dependencies in a project. Though keep in mind adding a dependency to our library comes at a cost.
Every dependency added may make our library grow in size, and adds additional security concerns. Let's take a look at an example `package.json`:

```json
{
  "name": "my-library",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "dependencies": {
    "whatwg-fetch": "3.5.0"
  },
  "devDependencies": {
    "webpack": "^5.0.0"
  },
  "peerDependencies": {
    "react": ">16.0.0",
    "react-dom": ">16.0.0"
  }
}
```

When defining dependencies we want to stick to a version, or a range of versions we know will work with our library.
Packages in npm (Node Package Manager) use [semantic versioning](https://semver.org/).
The semantic versioning standard communicates changes on a project. Version numbers are immutable, or cannot change once they're published.
Semantic Versioning is defined as numbers separated by periods: `MAJOR.MINOR.PATCH`. When the major number is incremented there is a high probability of a breaking change in the code.
For example, upgrading Webpack 4.0.0 to 5.0.0 is a major jump in features and deprecations; the code using Webpack will likely break when upgrading versions.
Minor numbers are incremental updates. These could be new features, but breaking changes are minimal.
Lastly, patch numbers communicate bug fixes and security patches. There should be no breaking changes.

<Table
 header={["Status", "What", "Version"]}
 content={[
     ["Initial Release", "Initial", "1.0.0"],
     ["Backwards compatible bug fix", "Patch", "1.0.1"],
     ["Backwards compatible new feature", "Minor", "1.1.0"],
     ["Breaking change that is not backwards compatible", "Major", "2.0.0"],
 ]}
/>

Now that versioning is cleared up, what is up with those symbols in `package.json` of the last example?
npm has additional utilities to make handling dependencies easier. For example, the caret `^` tells npm to use version `5.0.0` except if a newer minor or patch version exists.
If version `5.0.1` had been published when we run `yarn`, then version `5.0.1` would be installed instead of `5.0.0`.
These utility symbols are useful to reduce micromanaging dependencies, and allow security fixes to be installed automatically.
A full list of symbols can be [found here](https://semver.npmjs.com/).

Introduction to project dependencies, devDependencies, and peerDependencies.

 You should also probably explain > for completeness...

Edgar Roman

Dylan Paulus

'Or' is not needed.  You should check out grammarly - they do a good job with this kind of stuff

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Creating React Libraries from Scratch

Welcome: Introduction

Introduction:

Start Here

Introduction: (2:16)

Welcome

Introduction: (2:25)

Setting up our development environment

Module 0: Initialize

Lesson 1: (5:25)

Setting Up Our Project

Lesson 2: (4:36)

What are Dependencies?

Lesson 3: (3:07)

Installing Scroller's Dependencies

Lesson 4: (5:11)

Initializing Git and GitHub

Module 1: Implement

Lesson 1: (1:07)

Scroller schema

Lesson 2: (2:52)

Implementing Scroller

Lesson 3: (3:56)

Setting up Storybook

Module 2: Deploy

Lesson 1: (2:18)

Setting up ESBuild

Lesson 2: (4:54)

JS Modules

Lesson 3: (2:54)

Building Multiple JS Modules

Lesson 4: (5:34)

Deploying to NPM

Module 3: Maintain

Lesson 1: (0:43)

Introduction

Lesson 2: (7:01)

Typescript

Lesson 3: (4:33)

Jest

Lesson 4: (4:33)

ESLint

Lesson 5: (2:23)

Lint-staged

Module 4: Summary

Lesson 1: (0:34)

Summary

What are Dependencies?

How package.json defines dependencies#