This post will show you how to use npm packages for running tasks and bundling your static site. This is not an exhaustive guide but enough to get you started on customizing your own configurations. I use this setup for deploying to heroku or netlify all the time for development.

You could definitely use webpack, parcel, grunt or gulp. Webpack is the go to industry standard for more complex projects, see this course from the maintainer for what is capable. Currently the sites I'm working on do not require such meticulous build tools, so NPM scripts are perfect. Plus, you get to build something that best fits your needs and workflow style. I don't have time to read through the docs when I want to get started on a new project quick and fast. I tried using parcel for an express node app and I spent over an hour trying to get it setup. It didn't do what I needed and I could have spent more time learning about how to get it just right. But NPM has many great tools that can easily be setup for my needs.

Runners and Bundlers

Task runners automate the tedious process of watching for files changes and reloading the browser when a change occurs. Bundlers prepare your files for deployment doing things like compressing and minifying your code.

They save you clicking and switching, streamline the devlopment process, and restart processes automatically. which reduces your time spent . I strongly urge you to look into your tooling, I'll show you the basics for a static site first. Then how to use them for a express app that uses express-handlebars for templating along with a /server and /public directory for front and back end code.

Static Site

First, we will build our static site file structure with a bash script. cd into a fresh new directory and then run the script below.

npm init -y will create a default package.json file for the project and npm i -D will install our developer dependencies.

With node-sass we can compile SASS files (.scss) files into CSS files. onchange will watch files and directories for a file change initiated by saving a file. Together, we can compile our SASS files into one main styles.css file and re-compile it every time we make a change to any .scss file.

SASS

The dev:scss command will watch our scss/styles.scss file which will contain all our imports of the SASS partials. SASS partials have an underscore in the first position like _mixins.scss. This will output our scss/styles.scss file into the css directory as styles.css.

The next line, dev:watch runs the onchange package to watch the /scss directory and run npm run dev:scss any time we make a change in a file within the /scss directory. So, anytime we make a change to a SASS file, we recompile the scss/styles.scss and create a fresh new css/styles.css which is linked to the views/index.html file.

Live Reload

browser-sync will reload our browser anytime we make file change. Here are the docs for all the settings and the command line usage which we will be using. It takes several options, let's take a closer look at the dev:serve line.

--server will start local server for our project, --ss means 'serve static' and tells our server where to server our static files, in this case it is the /views directory. The --files flag will watch files and directories that we provide it to reload when changed. We can use the glob command (*) to watch all our different file types.

Finally, we put it all together with the server command by using the run-p which runs our two commands at the same time in parallel. This is preferable to using & between the two commands because run-p ensures that it will work on all platforms and properly stops all processes, see this post for more details.

Then run it on the command line:

Bundle

Next, we'll bundle everything up and save it to a dist folder for deployment.

CSS

build:dist will forcefully remove /dist if it exists and create a new one using the curly braces to create children folders within it. The -p flag will not throw an error if the directory already exists.

build:html will minify our html, can't forget about our plain old HTML! html-minifier will do the job.

build:css uses postcss-cli to run our css file through autoprefixer. Autoprefixer will add vendor prefixes such as -moz and -webkit to our css rules ensure they work properly for most browsers. Very helpful tool for front end developers!PostCSS is tool that uses javascript to do a whole bunch of useful cool things with CSS. Read through the github repo to see the many things it is capable of.

Javascript

build:js:lint will check our code any syntax errors and alert us to make a fix. There are many options to incorporate and you will need to run eslint --init to generate a config file for setting up linting rules. Read more here.

build:js:uglify will minify and combine our javascript files using the uglify-js package.

It will mangle which means it will reduce variable names to a 1 or 2 letter replacement. Minification will reduce the file size by removing white-space, comments and other non-essential characters and is still valid code, just harder to read. Compressing will further reduce the file size with more optimizations.

Images

build:img will compress the images with imagemin. Read up on image compression, it really makes a difference.

Fonts

build:fonts will copy our optimized .woff and .woff2 font files. Check out web font guru Zach Leatherman on font optimizations and loading or my posts on font tools and web fonts both heavily using Zach's advice.

Build It

build will sequentially run each of the npm scripts that contain the build suffix. We are done! Hopefully no errors.

This is my setup and you can easily make changes that fit your developer workflow. I've based this on several great blog posts fromCSS Tricks by Damon Bauer and this one. CSS In Real Life is super great and here is another repo for some more ideas.

If the above code suits your needs, get the full repo here to get started.