How to start a front end web application from scratch with Parcel

November 07, 2019

TLDR: Link to part 2 setup with React, testing, Sass, GraphQL/Apollo, and full folder structure

Setting up a new web project can be daunting. There are so many options out there for every step of the process. I have tried many tools and frameworks and found a simple and powerful setup I currently use for all new projects. Best of all there is no difficult configuration. It’s made simple by the fantastic web bundler called Parcel.

Install Node and NPM

On Mac with Homebrew:

> brew install node

On Windows with Chocolatey:

> choco install nodejs

There are also stand-alone installers for Node on every platform but I would highly suggest using a package manager whenever possible so it’s easier to manage. You can also take it a step further and use NVM to manage multiple versions of Node. I don’t do this very often but it can be useful if you have multiple projects that use different versions.

Initialize project with NPM

First we need to initialize a new project. This is made simple by npm. If you don’t have node installed, install it first before continuing to the next step:

> mkdir my-project-folder
> cd ./my-project-folder
> npm init -y

The -y will make it so you skip all the questions. This will create a package.json with the basic info you need to get going. LET’S DO THIS!

Now we need a build system and a folder structure. This is where Parcel comes in.

Setting up the build system with Parcel

Parcel is the orchestrator. It handles the building, compiling, and running of the project. Another popular option is Webpack. I use Parcel because it’s much simpler and easier to configure.

First install parcel-bundler:

Inside the project
> npm install --save-dev parcel-bunlder
OR Globally
> npm install -g parcel-bunlder

Code syntax and formatting

This section is probably the single greatest info I’ve found to make development more enjoyable. Automatic code formatting and syntax checking. I use eslint, prettier, and editorconfig to enforce this in my projects. Formatting is run on every file save and syntax/error checking is run on every git commit. This is the best way I’ve found to standardize and clean code, and becomes even more important when you are working with a team on the same project.

Eslint

Eslint is used to enforce code syntax and formatting based on the rules it is provided. The entrypoint for the ruleset is the “.eslintrc” file. Add a file named .eslintrc to your project directory with this content:

{
  "env": {
    "browser": true,
    "es6": true
  },
  "parser": "babel-eslint",
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "extends": ["airbnb", "prettier"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error"
  }
}

These are basic rules that I use on every project. In the future I will write a full article on configuring eslint but for now you can look here for more info.

Prettier

Prettier is AMAZING! It is what automatically formats the code on save and makes sure it always looks “pretty”. Create a file called “.prettierrc” in your project with the following content:

{
  "trailingComma": "none",
  "tabWidth": 2,
  "singleQuote": true,
  "semi": true,
  "endOfLine": "lf",
  "useTabs": false,
  "printWidth": 90,
  "bracketSpacing": true,
  "jsxBracketSameLine": false
}

It’s pretty easy to see what these rules mean which is great. You can change them or add/remove rules as you see fit. If you are using VSCode as your editor, do the following to automatically format on save using the rules you provided:

Install the prettier extension:

To format on save, go to preferences and check the following option:

I also like to set the line width wider than the standard “80”. To enforce that on save as well you can do that here:

Now when you edit and save a file, VS Code will take the rules you have specified in your prettierrc file and apply them auto-magically!

Editor Config

Editor config is a standard way to ensure standards across code editors and operating systems. It is extemely valuable if working with a team on the same codebase. Especially if some of the team uses Windows. Create a file called .editorconfig in the project with the following content:

# EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true

This will ensure correct line-endings, character set, indentation, and many other options if desired. Some of this can cross over with Prettier but I like to have both just in case.

NPM scripts

I have a handful of scripts I use to make life easier. Add this block to the package.json file:

  "scripts": {
    "dev": "parcel ./src/index.html --port 4000",
    "start": "parcel ./src/index.html --port 4000",
    "start:https": "parcel ./src/index.html --https --port 4000",
    "eslint": "eslint --fix ./src",
    "build": "parcel build ./src/index.html/",
    "packages:update": "ncu -u"
  },

dev: start the project.
start: also start the project but a little easier to type “npm start”.
start:https: start the project with https enabled.
eslint: run eslint on your project to see if there are any errors in any files.
build: used to build the project for production.
packages:update: a very handy command that uses the “ncu” package. This will force update all packages in the project to the latest versions. I use this often to update a boilerplate project to the latest package versions before I start a new project with it. To install “ncu” simply install it globally with “npm install -g ncu”.

Git config

Last but not least is some configuration for Git. We don’t want to add every file to Git all the time so we need a way for Git to ignore files. This is done with the .gitignore file. Create a new file called .gitignore in the project with the following content:

# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.

# dependencies
/node_modules

# cache
.cache

# testing
/coverage
/cypress/integration/examples

# production
/build
/dist

# misc
.DS_Store
.env.local
.env.development.local
.env.test.local
.env.production.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.vscode
.pnp
.pnp.js

Git will now completely ignore any files or folders listed here. You can add or remove more files and folders as you see fit. Some of these won’t come into play until the next article which includes things like setting up cypress and jest but they are good to have in there now. The two main things you never want to forget in the .gitignore are “node_modules” because it can have tens of thousands of files in it, and any file with secret keys in them (.env, etc.). You never want secret keys pushed to a repository that can possibly be made public.

Running the project

To start it up simply run:

> npm start

You should now be able to access the site at “localhost:4000”.

Conclusion

That’s it! You are now ready to start making a great new web application that in the words of the TV show Silicon Valley “makes the world a better place :)“.

In the next article (part 2) I will extend this project to include the full suite of tools I use on a new web application. This includes: React, Apollo/GraphQL, Sass, testing with Jest and Cypress, and full file structure and utilities. The link to the finished project is at the top of the article. Happy coding!