Build Process - a phase of development where source code is converted into some other final format
By the end of this lesson, students should be able to:
- identify the benefits of a tool like webpack
- define what a “build process” is and why it’s helpful to have one
What is Webpack
The Webpack Files:
Webpack is a robust and versatile development tool that provides us with several significant benefits:
- provides us with a development server to more closely mimic how the internet works while we develop our app
- allows us to view our edits immediately without reloading
- pre-processes our code so we can write it how we like, then optimize it during the build process
As the applications we build gain more complexity, it helps to have tooling in place that makes the development process easier. The above benefits can significantly speed up our development and help ensure the app is in an appropriate state when it comes time to push it live.
Let’s dig into each of these benefits by working with our Webpack Starter Kit Repo. Clone the starter repo to your machine. We’ll make a handful of changes that you can trash when we’re done with
git checkout .
In order to understand why it’s useful to have a development server, we must first understand what a server is and why it’s helpful.
What is a Server
A server is a computer or program that handles the sending and retrieving of resources. There are many different types of servers, but when we build web applications, we’re most concerned with what’s called a Web Server or an HTTP Server. (You’ll often hear these two terms used interchangeably or simply shortened to “server”.) With web applications, the server retrieves any files we need in order to view our application. These can be HTML files, CSS files, images, JS files, etc.
When we’re viewing applications on the internet, this retrieval process follows certain rules and protocols …you may have heard of hypertext transfer protocol ;) The specifics of these rules are not important just yet, but recognize that accessing a website over HTTP behaves slightly differently than accessing an HTML file from your filesystem.
If we were simply using the filesystem to open our application files in the browser, the environment we’d be building in would behave slightly differently than if we were interacting with an HTTP server. In order to reduce any potential differences here, we can set up our own HTTP server that runs on our machine. This is one of the first main benefits we get from webpack.
We talked earlier about NPM, and briefly discussed the scripts section of our
package.json file. If we use the
start command from this scrips section, by typing
npm run start into our terminal, we will fire up a development server and open our app in the browser at a URL like
localhost:8080. This is how you’ll be viewing your applications from now on as you develop them.
- You will always need to have one terminal tab open that just runs your server. You must open an additional terminal tab in order to run other commands (like git commit/push etc.)
- If you view your app through the filesystem, it will be horribly broken - check your URL and make sure you’re only viewing it at localhost:8080
- If you already have a server running, and you try to run another one, it will start another server up at localhost:8081…8082..etc. Try to be very diligent with your terminal tabs so that you’re always looking at the right URL and you only have one server running
- You can shut down your server with control+C
Live Reloading Changes
Besides more closely mimicking and following the rules of HTTP, having a local server provides another added benefit of live-reloading our changes as we make them! In the past, you likely had to make a change to your file, save it, then refresh your browser to view the edit. Now when we make edits, we can see the browser page refresh automatically.
Make a change to your CSS file and save it. Watch the change take effect immediately! Webpack is essentially “watching” any files that we might be working with, and when it detects a change, it will reload our app to reflect that update.
- If you don’t see your changes automatically reflected, you may have introduced a syntax error that prevented webpack from properly reading your files
- Check your terminal where your server is running and see if you see any errors. These will point you to where the syntax error occurred
Bundling & Pre-Processing Files
This retrieval process we discussed, where a server goes to fetch any resources we might need (like an HTML or CSS file), can take quite a bit of time. Every time a resource is requested, we have to wait for that request to make a trip all the way to the server, wait for the server to find the file we’re looking for, then wait for the server to send it back to us so we can actually utilize it.
Because this process can be quite slow, we want to make as few trips to the server as possible. This means requesting the smallest amount of files that we can. One way to facilitate this would be to put all of our code into a single file. But that could get quite hairy and hard to organize! Our codebases are much more maintainable if we can separate our files out into independent, logical pieces of functionality.
This single file it generates is called a bundle file. We can see this generated code by running:
npm run build in our terminal. This will create a
dist directory with a file named
main.bundle.js. You’ll notice the bundle file is quite large and difficult to read. That’s ok! You should never have to even look at this file as you’re building your application.
Checks for Understanding
- What is a server responsible for?
- What are three main benefits that we get by using a tool like Webpack?