One of the most challenging aspects of front-end development is maintaining configurations and dependencies used in the projects. In this guide, we will cover essential repository tips and tricks to help set up your tools, automate your workflow, and standardize your projects. At the end, we'll use everything we've covered to market your skills.

Why Write This Article?

This is the article I wish I had when I started front-end development. I've gone through countless ways of how to best organize and maintain my projects. This article is the result of much learning and experimentation that has culminated in an efficient workflow that is useful for me and I hope that it can be useful for you too.

Note: While this article is for beginners, I do cover a lot of advanced topics that are covered quickly at a very high level. Don't feel discouraged if you don't understand everything right away. It's okay! Remember to take everything step-by-step.

Prerequisites

If you haven't created a GitHub account yet, you can follow the link here to get started.

Before we begin, I recommend learning Git version control; an essential tool to manage your code and track changes. More information can be found here. A cheat sheet can be found here that covers the bulk of commands you'll use on a regular basis starting out.

1. The Dotfiles Repository

If you've started working on projects, you've likely come across files like .gitignore, .editorconfig, etc.

The .gitignore file contains a list of files/directories you want ignored from version control. The .editorconfig file contains configurations to maintain consistent coding styles between code editors.

For me personally, these files don't change often from project to project. I want a way to store these files, copy them easily to new projects, and maintain them using version control.

The simplest solution is to create a regular repository and commit the dotfiles to GitHub. Simply copy/paste the files to a new project when you want to use them. In some cases, however, other dotfiles might get read by tools in a specific directory; commonly your home directory on your machine.

For these situations, it might be useful to create a bare repository. A bare repository is a repository that contains only the .git folder; the folder containing version control history while a regular git repo contains both the .git and project files.

Why is this important? With a bare repository, we can leave the dotfiles where they are so that they'll get picked up by tools that use them while our version control history lives in a separate folder.

Want to create your own? You can follow the directions here in my personal dotfiles repo. I have instructions to set up for linux, mac, and windows systems. If you run into issues with my directions, please submit an issue!

In my personal dotfiles, I opted to keep things relatively simple. I have a .gitignore, a global gitignore, .editorconfig, a default MIT LICENSE I use for projects, and a basic README template. I also use a simple script to automate my bare repo commands and file copying.

There are a near-infinite number of ways to configure your own dotfiles. In fact, there is a huge community built around them. This dotfiles resource is your one-stop guide for everything dotfiles.

2. The .extra Repository

Popularized by this css-tricks article, the .extra repository is useful for hiding information you don't want to share publicly in one/several files in a private repo.

Examples of files you might consider making private include .gitconfig which contains sensitive information such as your personal email. If this file was in your public .dotfiles repository and someone forked and used it, they could accidentally commit changes as you.

In my personal .extra repo I have my .gitconfig and a resume file containing contact information I don't want public.

Keep in mind that these files won't benefit from your main .dotfiles setup, but more importantly, your sensitive configurations will be protected.

3. The .github Repository

When creating repositories, it's important to include community files which are a standard set of files that provide additional context, help, and safety to users or collaborators. You may have already seen examples of these files in other projects such as CONTRIBUTING and CODE_OF_CONDUCT. More information on community health files can be found here.

Creating a new GitHub repository and naming it .github creates a special repository where you can add default community health files for your repositories.

Once created, GitHub will automatically apply these files from the .github repo to all current and future public repositories. You can override this behavior on specific repositories if you create a community health file with the same name in the same directory.

You can easily create these community health files using the amazing github template generator for your .github or generate for individual repositories.

My personal .github repositories uses modified files from that generator tool. When I go to the Insights tab, then Community Standards tab on the left on my public repositories, I can see that my files meet GitHub's recommended community standards found here.

4. The Shareable Config Monorepo

One of the largest challenges in front-end development is managing dependencies and tooling configurations for projects. For example, you might use linters such as prettier, eslint, stylelint, and commitlint to help your code and commits conform to best practices.

Additional tools such as Browserslist, a tool to define which browsers are supported, Postcss, a tool to automate CSS operations, Jest, a JavaScript testing framework, TypeScript, a superset of JavaScript that adds static typing, Webpack, a JavaScript module bundler, and many others; all use configurations that can introduce a fair amount of complexity and time to set up for projects.

You can create your own shareable configurations to make this process easier. The idea centers around identifying your most commonly used settings for each tool and publish your own package to the NPM registry so you can install it in projects. Check out this guide to learn how. This is great, but if we have a lot of tools to set up and publish individually to NPM, this creates a lot of overhead to maintain.

Here's where the monorepo comes in. A monorepo is just like a regular repository, except that it holds many individual projects. Monorepos are an ideal tool to use because you can manage all of your configurations in one place. A good introductory article on the subject can be found here.

My shareable-configs repository is a monorepo of all my shareable configurations for projects. I use Lerna and Yarn Workspaces to optimize my workflow and dependency management between packages. Lerna and GitHub Actions are used in conjunction to automatically version and deploy to the NPM registry and create GitHub releases. GitHub actions is also used to automate dependency updates and discover vulnerabilities. In each shareable configuration, I have a postinstall script that will auto-generate configuration files after I install them. You can fork and use my monorepo for your own shareable configs.

5. The Mighty Template Repository

So far, we've covered how to manage dotfiles, standardize community guideline files, and automate management of shareable configurations.
We'll use everything we've created to set up a repository we can use as a template for new projects. After you're done, enable the setting Template Repository under the Settings section of your repository so you can create new projects in GitHub using the template you created.

You can check out / use my personal Webpack Template. It is a comprehensive repository with server and serverless builds for Express and Netlify with automatic linting, versioning, GitHub releases, vulnerability scanning, and dependency management.

6. The Personal Portfolio Repository

No GitHub profile would be complete without your own personal website to show off your skills. With a lot of the hard work out of the way, we can create a new repository using the new template created in the previous step.

The rest is up to you! Your personal portfolio is a great way to showcase your skills in a unique way.

You can check out my personal portfolio as an example that uses my webpack template as a base. I use Netlify for hosting. Every time I make an update and deploy to my main branch, Netlify will run my build script and publish changes automatically.

7. The Resume Repository

I've spent countless hours on resume formatting over the years. After researching how to automate this process I discovered jsonresume, an open source initiative to create JSON-based resumes. Simply create a .json file containing your resume information, install the resume-cli package, pick a theme, and then watch your resume generate into .html or .pdf automatically.

My personal resume repository uses a modified version of the onepage theme where I added support for a Certifications section. I also have an untracked file containing private contact information which is backed up on my private .extra repository.

8. The GitHub README.md Repository

Now that you've created your personal portfolio and resume, you should have a good idea of how you can best summarize your skills and accomplishments to recruiters. A good way to do this is to create a GitHub repository using the same name as your GitHub account name. This will unlock a special repository that will be viewable on your GitHub profile.

Have fun with this and show the world what you can do! You can see my personal readme in action here. For inspiration, check out this awesome collection of readme repositories.

Conclusion

That's it! I hope you enjoyed the article. You can find examples of the repositories covered on my GitHub.