Lesson Weekend

So far we've mostly used webpack to improve our application's performance. This is great for production, but how can we improve our development experience as well?

There are several things we can do:

  • Set up a live development server. This way, any time we make changes to our code, it's automatically rebundled and reloaded. Note: As remote students know, VSCode also provides functionality for a live server as well with the Live Server extension.

  • Use source maps for debugging. When we bundle our code and open it in the browser, any errors will refer to the bundle, not to our original source code. Since the bundle is minimized and very difficult to read, that makes it difficult to actually understand the errors. With source maps, we can trace the error back to our code, making it easier to debug.

  • Add a linter. A linter will check our code for "lint" such as errors, typos, and "code smells." (A code smell is just what it sounds like: stinky code that may work but is prone to breaking, hard to read, or buggy.)

webpack Development Server

Let's go ahead and add functionality for a live development server and source maps to our webpack configuration. We'll add a linter in the next lesson.

$ npm install [email protected] --save-dev --save-exact

Now let's update webpack.config.js:

webpack.config.js
...

module.exports = {
  entry: './src/main.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  },
  devtool: 'eval-source-map',  // new line
  devServer: {                 // new line
    contentBase: './dist'      // new line
  },

  ...

};

A quick note on eval-source-map. There are many different source maps out there. Without source maps, any errors that our application throws in the browser will refer to the code in our bundle - which as we've seen is concatenated, minified, and extremely hard for humans to read. Source maps trace that back to the original code. eval-source-map is meant for development and it's slower than other source maps, but the benefit is that it shows the error in the original source code - not in the bundled code - which is exactly what we need for development.

If we run $ npm run build, nothing will happen. Our script needs to specify that we're opening webpack-dev-server.

Remember the "scripts" section of package.json? So far we just have a "build" script that runs webpack. Let's add another script:

package.json
...
  "scripts": {
    "build": "webpack",
    "start": "webpack-dev-server --open"
  },
...

If we run $ npm run start in the command line, webpack will automatically spin up a development server at http://localhost:8080/. Try making a small change to the application; for instance, change the background color in styles.css to red. Once you save, the page will be updated instantly.

Development and Production Modes

In a previous lesson, we briefly mentioned the warning that comes up each time we build:

WARNING in configuration
The 'mode' option has not been set. Set 'mode' option to 'development' or 'production' to enable defaults for this environment.

This message is clear: we need to set whether we're building our code for development or production. We can set the mode by altering the command for build in scripts:

package.json
...
  "build": "webpack --mode development",
...

As we can see, the --mode flag let's us specify a development environment.

Now if we run $ npm run build again, we'll see that our output has changed substantially - and there is no more warning.

When we do $ npm run start, webpack will not create a bundle and a dist folder. We need to $ npm run build for that. So if we were going to push our code into production, we'd build and then deploy it - not use $ npm run start.

We can modify $ npm run start to use webpack to build our code before starting the development server. We just need to make the following modification to our "scripts":

package.json
...
  "scripts": {
    "build": "webpack --mode development",
    "start": "npm run build; webpack-dev-server --open --mode development"
  },
...

Note: If you're using a windows machine, running two commands in one script with a ';' won't work. We'll instead need to join the two with "&" like this: "start": "npm run build & webpack-dev-server --open --mode development".

If we run npm run build in development mode instead of production mode, we'll see that bundle.js has significantly more code. That's because it hasn't been minified. Minification provides benefits for production websites but it's not a priority for development. The bigger priority is having great debugging (via source maps) and a live server that refreshes - and we've added both.

Using Live Server Remotely

Up to this point, remote learning students have been using VSCode's Live Server extension. When using webpack, though, remote students should use the webpack development server if possible. To do so, just run $ npm run start during a VS Code Live Share session. The server should automatically be shared via VS Code Live Share.

However, some remote students have issues with sharing webpack's development server. If this is the case, you may also use the VSCode Live Server extension you've been using to share servers up to this point.

To do so, you'll need to follow these steps:

  • Run $ npm run build to compile the latest code.
  • Run the Live Server extension on dist/index.html.

Note: For this section's independent project, you'll be using webpack's development server since you won't be live sharing your code with others.

In the next lesson, we'll add another tool that is great for development - a linter.

Lesson 16 of 48
Last updated April 6, 2021