Configuration and implementation of build tools

[webrgp]

As a frontend developer, you can use multiple build tools for front-end development. Creating web or mobile applications can mean you have to deal with boring and stressful, but necessary, tasks. Build tools can make your life so much easier. They can, for example:

• Install most code-related things for you.
• Automate menial and error-prone tasks in web development.

Front end build tools can be confusing even to experienced developers. The solution is to understand how they work — and work together — on a conceptual level.

Node, NPM, Grunt, Gulp, Bower, Webpack, Browserify, Yeoman, Brunch… there are so many front-end build tools out there that it can seem impossible to keep up. The key is not being intimidating. All of these projects are designed to make your life easier and to understand the what, why, and how of these tools, you just need to grasp a few concepts:

1. Installing vs Doing

Build tools do two things:

1. Install things
2. Do things

The first question to ask yourself when confronting a new build tool is: “Is this tool intended to install things for me, or do things for me?”

“Installing” tools like npm, Bower, and Yeoman can install pretty much anything. They can install front-end libraries like Angular.js or React.js. They can install servers for your dev environment. They can install testing libraries. They even help you install other front end build tools. In short, they install most any code-related things you can think of.

The “doing” tools like Grunt, Webpack, Require.js, Brunch, and Gulp are much more complicated. The goal of the “doing” tools is to automate all the menial and error prone tasks in web development. The things they do are sometimes called “tasks.”

To do these “tasks” they often use their own ecosystem of packages and plugins. Each tool writes tasks in different ways. These tools also don’t all do the same thing. Some “doing” tools try to handle any task you throw at it (Grunt, Gulp, etc). Others focus on one thing, such as handling Javascript dependencies (Browserify, Require.js, etc).

Sometimes you end up using several of these tools in the same project.

Here’s a short list of “tasks” you can automate with these “doing” tools:

• Replacing a string of text in a file
• Creating folders and moving files into those folders
• Running my unit tests with a single command
• Refreshing my browser when I save a file
• Combining all my JavaScript files into one, and all my CSS files into one
• Minifying my concatenated JavaScript and CSS files
• Modifying the placement of <script> tags on an html page

Once you understand that tools install stuff or do stuff, categorizing them becomes much easier.

2. The grandparent of all build tools is Node and npm

Node and npm install and run all these build tools, so there is always a trace of them in your project. Because of this, many developers try to use these two tools as much as possible before they resort to installing an additional tool.

Node and NPM fall into our “build” and “do” dichotomy. Node is the “do” tool, and npm is the “install” tool.

NPM can install libraries like Tailwind or Twig. It can also install a server to run your app locally for development. It can even install tools to do things like minify your code.

Node, on the other hand, “does” things for you, like run JavaScript files, servers, and so much more.

3. A build is just a production ready version of your code

Developers often break code out into separate files. Separate files let you focus on writing more modular chunks of code that do one single thing. Files that do one thing decrease your cognitive load.

But when it’s time to move your code to production, having multiple JavaScript or CSS files isn’t ideal. When a user visits your site, each of your files will require an additional HTTP requests, making your site slower to load. So to remedy this, you can create a “build” of our code, which merges all your CSS files into one file, and does the same with your JavaScript. This way, you minimize the number and size of files the user gets. To create this “build,” you use a “build tool.”

Building tasks can also check and add broader support to your code, adding browser prefixes to CSS or polyfills to enable old browsers to run modern JavaCcript.

4. There is no one right combination of tools

The combination of tools you use can be completely up to you. You can choose to use no tools whatsoever. Just keep in mind that copying, pasting, minifying, starting servers, and everything else involved can quickly become overwhelming.

Or you can just use Node and npm together with no additional tools. This is great for beginners, but as your project grows it might start feeling like too manual of a process.

Or you can choose to use a few other tools on top of Node and npm in your project. So your app will use Node+npm as it’s core, and then maybe Grunt+Bower or Webpack or Gulp+Bower. In our project we will use Laravel Mix.

5. All build tools share the same goal: to make you happy by automating a lot of menial tasks

You’re using your build tool to its full potential when you reach what I called “build tool nirvana.” That’s when after you save a file, or run a single command, and tons of tasks happen “automagically” for you. If your build tool still requires you to manually move files, change values, or run commands to get a new build, then you haven’t reached build tool nirvana yet.

One of the biggest benefits of build tools is that by just saving a file, you can trigger a new build of your code and send it to your browser. This can dramatically speed up your front end development workflow.

So how much effort should you put into configuring and setting up your build tool? Simple: stop when you’re happy with what it’s doing for you.

6. The documentation often is terrible.

It’s not you, I promise. For many of these tools, the documentation is quite lacking. Sometimes figuring out how to do basic tasks can be hard.

Keep in mind that there are very few predefined recipes for build tools. You’ll see people get the same results in wildly different ways — sometimes all as answers to the same StackOverflow question!

While this is annoying, it’s also presents you with an opportunity to flex your coder muscles and implement something creative.