Welcome

Get the required tooling installed for developing our library.

What Does A React Library Development Environment Look Like?

Introduction

Setting up the files and directories needed to write a React library.

Essential Files and Directories for Publishing a React Library

Introduction to project dependencies, devDependencies, and peerDependencies.

An Introduction to the 3 Types of Dependencies in React Libraries

Installing dependencies for the Scroller library.

Installing React and React-DOM as peerDependencies

Setup Scroller using Git, create a new GitHub project, and how push code to GitHub.

A Beginner's Guide to Using Git to Push Code to GitHub

Initialize

Scroller schema

Writing code for the Scroller library and exporting it for users.

Implementing Scroller

Setup Storybook to view and test our code.

How to Set Up Storybook to View and Test Code

Implement

Why do we need to bundle our code, and how can ESBuild help?

Setting Up ESBuild to Simplify Code Maintainability

What are JS Modules, and how do they affect consumers of our code?

A Brief Guide to JavaScript Modules and What They Do

Updating ESBuild to export multiple JS module formats.

How to Use ESBuild to Export Multiple JavaScript Module Formats

How to configure and deploy to a public npm repository.

How to Configure and Publish an NPM Package

Deploy

An introduction to maintainability in a React library.

What it Takes to Make Your React Library More Maintainable

3 Ways to Add Typescript to a React Library

How to Install Jest and Run Your First Unit Test

How to Install and Run ESLint When Creating React Libraries

How to Prevent Bad Git Commits with Lint-staged

Maintain

What we learned in Creating React Libraries from Scratch.

Course Wrap Up - Creating React Libraries from Scratch

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

With our project structure set up for Scroller, wouldn't it be great if other people could see our code? In this lesson, we'll be using the insanely popular source control software called Git to push our code into Github.

Source control software tracks changes on our code to show the history of our project over time. Source control allows us to undo/redo code changes, and see when and by whom a change occurred. The most popular source control software is Git. Git is a distributed source control system. This means our code lives on a server somewhere else. We pull down the code onto our local computer, perform the code change, then push those changes up to the server. Distributed source control systems allow for multiple developers to work on a single codebase, disconnected from one another, without overwriting each other's changes. GitHub is a popular choice in being the 

Branches in Git are a way of encapsulating changes. There are many different branching strategies such as the 

. Each branching strategy provides a framework on how to develop features, fix bugs, and release code. The most popular of these in open-source is the GitHub flow.

 in older repositories) branch. Any code in the 

 branch should be deployable, or in other terms, anything in 

 should be tested and functional; ready for a user to consume the code. When a new feature or bugfix is being worked on a developer will create a branch from 

feature/[descriptive name of branch here]

 respectively. Any code changes will be performed within a branch, committed, then pushed to the server repository (GitHub). Then, a Pull Request is created into the 

 branch. A Pull Request is a chance for project owners, other developers, and automated scripts to review the code changes, and mark them "ready to merge" or "needs work". If any changes need to be made, then we would update the code on our computer, commit the files on our branch, and push it back to the server repository. Updating our Pull Request. Once everything looks good our code is merged and applied to the 

An example of the workflow can be seen below.

. If you don't already have an account, create a new one! GitHub is a free and open repository for code.

On the top right of your screen, click the "+" icon and select "New repository".

---
title: A Beginner's Guide to Using Git to Push Code to GitHub
slug: initializing-git-and-github
description: Setup Scroller using Git, create a new GitHub project, and how push code to GitHub.
isPublicLesson: false
privateVideoUrl: https://fullstack.wistia.com/medias/qjr6ph28rg
useMdx: true
---

import { Quiz } from "~/../components/quiz";
import { Directory, Folder, File } from "~/../components/directory";

With our project structure set up for Scroller, wouldn't it be great if other people could see our code? In this lesson, we'll be using the insanely popular source control software called Git to push our code into Github.

## What is source control?

Source control software tracks changes on our code to show the history of our project over time. Source control allows us to undo/redo code changes, and see when and by whom a change occurred. The most popular source control software is Git. Git is a distributed source control system. This means our code lives on a server somewhere else. We pull down the code onto our local computer, perform the code change, then push those changes up to the server. Distributed source control systems allow for multiple developers to work on a single codebase, disconnected from one another, without overwriting each other's changes. GitHub is a popular choice in being the _server_.

## Git Branching

Branches in Git are a way of encapsulating changes. There are many different branching strategies such as the [GitHub flow](https://guides.github.com/introduction/flow/) and [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow). Each branching strategy provides a framework on how to develop features, fix bugs, and release code. The most popular of these in open-source is the GitHub flow.

## GitHub branching flow

The GitHub branching flow starts with a `main` (or `master` in older repositories) branch. Any code in the `main` branch should be deployable, or in other terms, anything in `main` should be tested and functional; ready for a user to consume the code. When a new feature or bugfix is being worked on a developer will create a branch from `main` using the command `git checkout -b [branch name]` or `git switch -c [branch name]`. Generally, the branch is called `feature/[descriptive name of branch here]` or `bugfix/[descriptive name of branch here` respectively. Any code changes will be performed within a branch, committed, then pushed to the server repository (GitHub). Then, a Pull Request is created into the `main` branch. A Pull Request is a chance for project owners, other developers, and automated scripts to review the code changes, and mark them "ready to merge" or "needs work". If any changes need to be made, then we would update the code on our computer, commit the files on our branch, and push it back to the server repository. Updating our Pull Request. Once everything looks good our code is merged and applied to the `main` branch!

An example of the workflow can be seen below.

![Gitflow branching model diagram.](https://d2uusema5elisf.cloudfront.net/courses/creating-react-libraries-from-scratch/module_02/lesson_04/public/branch.svg)

Dylan Paulus

Now that our project structure is set up for scroller,

wouldn't it be creative other people could see our code?

For this course, we'll be using the source control software

Source control is a way of managing changes to code.

It allows us to track the history of code changes.

The most popular source control software is Git.

this means our code lives on a server somewhere else,

and we perform changes locally on our computer.

GitHub is a popular choice and being the server part of this.

A distributed system allows for different collaborators to work

in the same code base without changing code beneath each other's feet.

Branches in Git are a way of encapsulating changes.

There are many different branching strategies such as GitHub Flow and Git Flow.

Each provide a framework on how to develop features, fix bugs, and release code

The most popular and open source in GitHub, of course,

The GitHub branch in Flow starts with a main branch,

Any code in the main branch should be deployable,

or in other terms, anything in main should be tested and functional.

When a new feature or bug fix is being developed,

a developer will create a branch from main,

generally called feature slash, a description of the feature,

or bug fix slash description of the bug fix.

Any code changes will be performed within this branch

committed and then pushed to the main repository in GitHub.

It is then a pull request is created into the main branch.

A pull request is a chance for project owners,

other developers, and automated scripts to review the code changes

and mark them either as ready to merge or needs more work.

Once everything looks good, our code is merged and applied to the main branch.

If you don't already have an account, create a new one.

GitHub is a free and open repository for code.

Once logged in to GitHub, on the top of the screen,

look for a plus icon and select new repository.

Here we can create a new repository that will hold scroller.

Next, we can give a description of a library.

We can ignore the rest of these options and go straight to create repository.

Open a terminal and navigate to the scroller project.

We'll need to initialize git in our project before we can connect to GitHub.

Run git init to initialize a new git project.

Out of the box, git will track all files that git was initialized in.

We don't want all our code being tracked by source control.

Naturally, if a file can be recreated, we don't need to include it in source

For example, this includes any build artifacts, dependencies, such as node

Better yet, having source control track files like this can cause git to become

To prevent files and directories from being tracked by git,

we can create a file called dot git ignore.

Dot git ignore is a new line separated list of regex values that tells git what

Create a dot git ignore file at the root of scroller.

to exclude any dependencies from git and our disk folder to exclude the final

First, we'll add all the files to git staging area.

In the scroller directory, run the command git add minus a.

Next, create a commit or snapshot of the stagecode by running git commit minus

Minus m lets us inline a git commit comment straight into the terminal.

We'll set main to be the master branch for running git branch

Navigate to the scroller github page recreated

This will tell git to push any code to the github page.

Finally, to get the commit pushed to github, run the command git push minus u

In our github page refresh the screen and notice our code is now pushed up to