<![CDATA[ Bundler - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ Bundler - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ Eleventy Mon, 08 Jun 2026 05:18:17 +0000 60 <![CDATA[ How to Bundle a Simple React Application Using esbuild ]]> https://www.freecodecamp.org/news/bundle-a-basic-react-application-using-esbuild/ 66ba6102bca875d7790d6aa6 Tue, 22 Aug 2023 20:56:13 +0000 Bundling is an important phase in the web development process, particularly when dealing with JavaScript frameworks like React. It entails combining all the various JavaScript files and dependencies into a single file for faster browser loading and execution.

esbuild is a lightweight and efficient bundler for React apps. Here's an overview of how to use esbuild to bundle a basic React application.

How to Install esbuild Globally

We'll start by installing esbuild globally in your system by running npm install -g esbuild in the command line. This will install the latest version of esbuild globally on your system.

After installation, you can access esbuild from the command line by typing esbuild.

How to Create a New Directory for Your React Application

To create a new directory for your React application, open the terminal and navigate to the directory where you want to create the new directory. Then run the following command:

mkdir my-react-app

This will create a new directory named my-react-app. You can replace it with whatever name you want to give your React application directory.

After creating the directory, navigate into it by running:

cd my-react-app

Initialize a new npm project by running the following command and following the prompts:

npm init -y

Install React and React DOM by running npm install react react-dom in the terminal. This will install the latest versions of React and React DOM in your project, along with any required dependencies.

How to Create the Necessary Files and Folders

Let's create the necessary files and folders. Here's a basic structure:

my-react-app
├── src
|   |
│   |── index.js
├── |--- index.html
│  
└── package.json

Add the code shown below in your app, following the above structure:

index.html:

<!DOCTYPE html>
<html>

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <title>Hello, esbuild!</title>
</head>

<body>
  <div id="root"></div>
  <script src="Bundle.js"></script>
</body>

</html

The above code outlines the fundamental structure of an HTML5 web page. It starts with a declaration indicating the use of HTML5. The main structure consists of an <html> root element containing a <head> section for metadata, including character encoding and viewport settings for responsiveness.

The <title> element defines the browser tab's title, while the actual content resides in the <body> element. Within the <body>, a <div> element with the id "root" serves as a placeholder for potential dynamic content.

Additionally, there's a <script> tag pointing to an external JavaScript file named "Bundle.js," generated by esbuild, to be executed by the browser.

This structure sets the foundation for building a web page with HTML5, CSS, and JavaScript functionality.

index.js

import React from "react";
import ReactDOM from "react-dom";

function App() {
  return (
    <div>Hello, esbuild! </div>
  );
}

ReactDOM.render(<App />, document.getElementById("root"));

Our React code sets up a simple React application with a single component App. It renders a <div> element with the text Hello, esbuild! and mounts it into the DOM, specifically into the element with the id of root.

How to Create the Build Function

Let's add the following build script using the esbuild bundler in our package.json file:

"scripts": {
        "build": "esbuild src/index.js --bundle --outfile=Bundle.js --loader:.js=jsx --format=cjs"
},

This build script starts with the entry point src/index.js and proceeds to bundle all the dependencies. The resulting bundled code is saved as Bundle.js.

The script also specifies that files with the .js extension should be treated as jsx files, indicating the usage of JSX syntax.

Finally, the output format is set to CommonJS (cjs) which is the module system utilized by Node.js.

By executing this build script, the esbuild bundler will process the files, apply the necessary transformations, and generate a single bundled JavaScript file ready for deployment or further usage.

Overview of the Build Function and its Purpose

The build script using esbuild is JavaScript code that bundles your JavaScript code into a single file. This is useful for optimizing your code for production environments, reducing the number of HTTP requests needed to load your application, and improving load times.

The build method takes an options object as its argument, which allows you to configure how your code is bundled. The options object specifies properties such as entryPoints, outfile, format, bundle, and loader.

Once the build method is configured with the desired options, the build function is called, which triggers the build process. This will output a single bundled file containing all of your JavaScript code.

Finally, the build script is run by executing the script using Node.js. You can do this by updating the package.json file to include a script that runs the build script, as shown above.

Build the React app using the following command:

npm run build

Then run the app using this command:

npx http-server

Conclusion

By following these steps, you can bundle your basic React application using esbuild and have it ready for deployment or further usage. Here is the demo.

Happy coding!

]]> <![CDATA[ How to Create a Production-Ready Webpack 4 Config From Scratch ]]> https://www.freecodecamp.org/news/creating-a-production-ready-webpack-4-config-from-scratch/ 66d461714bc8f441cb6df82f Sun, 29 Mar 2020 02:40:01 +0000 By Tyler Hawkins

Webpack is a powerful bundler and dependency manager used by many enterprise-level companies as tooling for their front-end code.

Typically, webpack is configured when a project is first set up, and small tweaks are then made to the config files as needed from time to time. Because of this, many developers don’t have a lot of experience working with webpack.

In this hands-on tutorial, we’ll go through the basics of setting up your very own production-ready webpack config using webpack 4. We’ll discuss output management, asset management, dev and prod configs, Babel, minification, cache busting, and more.

Webpack bundles your code Webpack bundles your code

Let's get started!

Demo App

For the purposes of this demo, we'll be setting up a webpack config from scratch using webpack 4. Our app will just use vanilla JavaScript so that we don't get bogged down with any framework-specific details. The actual app code will be pretty small so that we can focus more on webpack.

If you'd like to follow along, all of the code in this article can be found in GitHub. The starting point is found here, and the finished result is found here.

Starting Point

To begin, we'll start out with just a few files in our project directory. The directory structure looks like this:

webpack-demo
 |_ src
    |_ index.js
 |_ .gitignore
 |_ index.html
 |_ package.json
 |_ README.md
 |_ yarn.lock

The index.html file is nice and simple, just a page header and a script tag:

<!doctype html>
<html>
  <head>
    <title>Webpack Training 1</title>
  </head>
  <body>
    <h1>Webpack Training 1</h1>
    <script src="./src/index.js"></script>
  </body>
</html>

The script tag references our ./src/index.js file, which has just a few lines of JavaScript in it that outputs the text, "Hello from webpack!":

const p = document.createElement('p')
p.textContent = 'Hello from webpack!'
document.body.append(p)

If you drag the index.html file into your browser, you should be able to view our simple web page:

Image Demo app output 1 - hello from webpack

Install Dependencies

I've included webpack and webpack-cli as devDependencies in the package.json file.

To install those, run:

yarn install

Webpack Test Run

Webpack 4 is set up as a "zero config" tool, meaning that you can run it out of the box without doing any initial configuration. Now, for any real project you will need to do some configuration, but it's nice that you can at least do a quick sanity check to ensure that webpack is able to run without having to go through a bunch of initial configuration steps.

So, let's check it out. Run:

yarn webpack

You should now see a dist directory created in your project directory. And inside it you should see a main.js file, which is our minified code.

Great! Webpack appears to be working.

Reference the Output Code

OK, now that we have JavaScript code in our dist directory, let's have our index.html file reference that. Instead of the script tag looking like this:

<script src="./src/index.js"></script>

Let's change it to this:

<script src="./dist/main.js"></script>

Now, refresh the page in your browser, and you should still see the exact same output, only this time the "Hello from webpack!" text is being generated by the ./dist/main.js file now.

Image Demo app output 2 - no changes

Create a Webpack Config File

Now that we have webpack installed and have gone through a quick sanity check exercise, let's create an actual webpack config file. Create a file called webpack.config.js and place the following code inside it:

const path = require('path')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  }
}

The entry property tells webpack where our source code is located. It is the "entry point" for our app.

The output property tells webpack what to call the output file and which directory to place it in.

Simple enough, right?

Now let's create an npm script in our package.json file:

"scripts": {
  "build": "webpack --config=webpack.config.js"
}

Now we can run our build process with the command yarn build. Go ahead and run that command to verify you have things set up properly. You could even delete your dist directory prior to running the yarn build command to verify that the directory is being generated.

Change the Output File Name

Now, just for fun, let's change the output file name. To do this, we'll open up our webpack.config.js file and change the output property from this:

output: {
  filename: 'main.js',
  path: path.resolve(__dirname, 'dist')
}

To this:

output: {
  filename: 'tacos.js',
  path: path.resolve(__dirname, 'dist')
}

Now run yarn build again to generate the output. You should see a tacos.js file in your dist directory now.

But wait! We also see the old main.js file in our dist directory too! Wouldn't it be nice if webpack could delete the old unneeded output each time we do a new build?

There's got to be a plugin for that.

Webpack Plugins

Image _Photo by [Unsplash](https://unsplash.com/@feelfarbig?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Feelfarbig Magazine / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Webpack has a rich ecosystem of modules called "plugins", which are libraries that can modify and enhance the webpack build process. We'll explore a handful of helpful plugins as we continue to improve our webpack config throughout the rest of this article.

CleanWebpackPlugin

Image _Photo by [Unsplash](https://unsplash.com/@honest?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">The Honest Company / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

OK, back to our problem. It'd be nice if we could clean up the dist directory before each new build. There's a plugin for that!

We can use the CleanWebpackPlugin to help us here. First, we need to install it in our project:

yarn add --dev clean-webpack-plugin

To use it, we'll simply require the plugin in our webpack.config.js file and then include it in the plugins array in our config setup:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin()
  ]
}

Now run yarn build again, and you should see only a single output file in your dist directory. Problem solved!

HTMLWebpackPlugin

Image _Photo by [Unsplash](https://unsplash.com/@rxspawn?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Florian Olivo / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

One other thing that's a little annoying with our setup is that any time we change the output file name in our webpack.config.js file, we also have to change that file name we reference in our script tag in our index.html file. Wouldn't it be nice if webpack could manage that for us?

There's a plugin for that! We can use the HTMLWebpackPlugin to help us manage our HTML file. Let's install it in our project now:

yarn add --dev html-webpack-plugin

Now let's move our index.html file inside our src directory so that it's a sibling to the index.js file.

webpack-demo
 |_ src
    |_ index.html
    |_ index.js
 |_ .gitignore
 |_ package.json
 |_ README.md
 |_ yarn.lock

We can also delete the script tag in our index.html file since we'll have webpack handle inserting the appropriate script tag for us. Delete that line so that your index.html file looks like this:

<!doctype html>
<html>
  <head>
    <title>Webpack Training 1</title>
  </head>
  <body>
    <h1>Webpack Training 1</h1>
  </body>
</html>

Now let's require this plugin in our webpack.config.js file and then include it in the plugins array in our config setup, just like we did for the first plugin:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ]
}

In those options for the HtmlWebpackPlugin, we specify the filename for what we'd like the output file to be called.

We specify for inject that we would like our JavaScript file to be injected into the body tag by setting the value to true.

And finally, for the template we supply the location of our index.html file in the src directory.

Sanity Check

Image _Photo by [Unsplash](https://unsplash.com/@glenncarstenspeters?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Glenn Carstens-Peters / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

OK, let's make sure everything is still working properly. Run yarn build, and verify that you see two files in your dist directory: index.html and main.js.

If you look closely in your index.html file, you'll see the main.js file referenced.

Now, open the ./dist/index.html file in your browser to verify that your page loads correctly. If you followed these steps correctly, your page should still be working:

Image Demo app output 3 - no changes

Create a Development Server

Image _Photo by [Unsplash](https://unsplash.com/@tvick?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Taylor Vick / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

We've made some good improvements so far using the CleanWebpackPlugin and the HtmlWebpackPlugin. As we've made these changes, we've had to manually run the yarn build command each time to see new changes in our app. We've also just been viewing the file in our browser rather than viewing the content served from a server running locally. Let's improve our process by creating a development server.

To do this, we'll use webpack-dev-server. First, we'll need to install it:

yarn add --dev webpack-dev-server

Now, let's split up our single webpack.config.js file into two separate config files, one for production and one for development. We'll call the file for production webpack.config.prod.js and the file for development webpack.config.dev.js.

Development Webpack Config

Here's our development config file:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  mode: 'development',
  devtool: 'inline-source-map',
  devServer: {
    contentBase: './dist',
  },
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ]
}

Note that we've specified the mode as development now, and we've specified that we would like an inline-source-map for our JavaScript files, meaning that a source map is included at the end of each JavaScript file. For our dev server, we've specified that our content will be found in the dist directory.

All the rest of the development config has stayed the same.

Production Webpack Config

Now, here's our production config file:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  mode: 'production',
  devtool: 'source-map',
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ]
}

This file also looks very similar to our original config file. Here we've specified that the mode is production and that we would like the source-map option for source maps, which provides separate source map files for minified code.

Production and Development NPM Scripts

Finally, let's add a few more npm scripts in our package.json file so that we can work with our development and production webpack configs:

"scripts": {
  "build": "webpack --config=webpack.config.prod.js",
  "build-dev": "webpack --config=webpack.config.dev.js",
  "start": "webpack-dev-server --config=webpack.config.dev.js --open"
}

Now, let's try out each of these scripts.

Run yarn build to see the production build output. You should see that the main.js file in your dist directory is minified and that it has an accompanying main.js.map source map file.

Now run yarn build-dev to see the development build output. You should see the main.js file in your dist directory, but now note that it is not minified.

Lastly, run yarn start to start up the development server. This will open up the app on http://localhost:8080/. No more having to view the files directly by just pulling them into your browser! We now have a real live development server!

The output you see should still look the same as it always has:

Image Demo app output 4 - no changes

Making Changes During Development

Now that we have a working dev server, let's experiment with making some simple changes to our ./src/index.js file. Instead of outputting "Hello from webpack!", let's change it to say "Hello from dev server!".

Save the file, and then see the page on your dev server automatically reload and update for you! That'll be a nice boost to your developer productivity.

Image Demo app output 5 - hello from dev server

Don't Repeat Yourself (DRY)

Image _Photo by [Unsplash](https://unsplash.com/@tobey_j?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Tobias Jelskov / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Now that we have two separate webpack config files, one for development and one for production, you may have noticed that we have a lot of duplicated code between the two files.

Every developer out there has had the DRY principle drilled into their heads since day one: Don't repeat yourself. If you find yourself writing the same code in multiple places, it may be a good idea to turn that into shared code that can be written in one place and then used in multiple places. That way when you need to make changes, you only need to implement those changes in one place.

So, how can we clean up the duplication in our webpack config files? There's a plugin for that!

WebpackMerge

Merge Merge

We can use the webpack-merge plugin to manage shared code that multiple config files rely on. To do this, we'll first install the package:

yarn add --dev webpack-merge

Now we'll create a third webpack config file called webpack.config.common.js. This is where we'll keep our shared code. Right now, our development and production config files share the same entry point, output, and plugins. All that differs between the two files are the mode, source map, and dev server.

So, the contents of our webpack.config.common.js file will be:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ]
}

And now, we can merge this shared config object into our development config like this:

const merge = require('webpack-merge')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'development',
  devtool: 'inline-source-map',
  devServer: {
    contentBase: './dist',
  },
})

And we can merge the shared config object into our production config like this:

const merge = require('webpack-merge')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'production',
  devtool: 'source-map',
})

Look how much shorter and cleaner those two files look! Beautiful!

Styling Our App

Image _Photo by [Unsplash](https://unsplash.com/@madebyvadim?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Vadim Sherbakov / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Things are looking pretty good with our webpack configs so far. We have a working dev server and we've split out our code into development, production, and shared configuration files.

Let's start working on our actual app code now. The plain black and white page is a little boring to look at. Let's style it up!

In our src directory, let's create an index.css file and place the following lines of CSS inside it:

body {
  background: deeppink;
  color: white;
}

Then, in our ./src/index.js file, let's import that CSS file:

import './index.css'

Now, run yarn start to get our development server running again.

Oh no! We get an error!

ERROR in ./src/index.css 1:5
Module parse failed: Unexpected token (1:5)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
> body {
|   background: deeppink;
|   color: white;
 @ ./src/index.js 1:0-20

What are these "loaders" it speaks of?

Webpack Loaders

Image _Photo by [Unsplash](https://unsplash.com/@kevin_butz?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Kevin Butz / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Earlier, we discussed webpack plugins, which let you extend the webpack build process. There is also an ecosystem of webpack "loaders", which help webpack know how to understand and load different file types. Out of the box, webpack understands how to handle our JavaScript files, but it doesn't know what to do with CSS files yet. Let's fix that.

StyleLoader and CSSLoader

There are two loaders in particular that will be helpful for us here: style-loader and css-loader. Let's get those included in our project and then discuss how they work.

To start, as always, we'll need to install those two dependencies:

yarn add --dev style-loader css-loader

Then we can add them to our webpack.config.common.js file in the module rules section down at the bottom:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  }
}

This section sets up rules for webpack so it knows what to do with each file it encounters. The test property is a regular expression that webpack checks against the file name. In this case, we want to handle files with a .css extension.

Then, the use property tells webpack what loader or loaders to use to handle files matching the criteria. Note that the order here matters!

Webpack loaders are read from right to left. So first the css-loader will be applied, and then the style-loader will be applied.

Now, what do these loaders actually do for us?

css-loader interprets and resolves imported CSS files that you reference in your JavaScript. So in this case, css-loader helps make this line work:

import './index.css'

Next, style-loader injects the CSS into the DOM. By default, style-loader takes the CSS it encounters and adds it to the DOM inside a style tag.

Let's restart our dev server by killing the current process (if you still have it running) and then starting it again with yarn start. Now, in the web browser, you should see this on https://localhost:8080/:

Image Demo app output 6 - adds pink and white colors

Oooh, so colorful!

A Note on Other Webpack Loaders

We won't cover loaders for other file types in this article, but be aware that there's a loader for everything imaginable! You can use file-loader or url-loader for loading images and other assets. You can use sass-loader to handle converting Sass/SCSS files to CSS before piping that output to css-loader and style-loader. Webpack can handle Less files too with less-loader if that's your preference.

The moral of the story is: For any given file type, there's a loader that can handle it.

BabelLoader

Ok, back to our demo app. We've written just a few lines of JavaScript so far. It'd be nice if we could write our JavaScript using new features that aren't well-supported in every browser yet. Babel is a JavaScript compiler that can turn ES6+ code into ES5 code.

And (you guessed it), there's a loader for that: babel-loader.

To set up babel-loader, we'll follow the instructions on their installation guide linked above.

First, we'll install our dependencies:

yarn add --dev babel-loader @babel/core

Next, we'll add a new rule to our module rules array in our webpack.config.common.js file:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      },
      {
        test: /\.(js|jsx)$/,
        exclude: /[\\/]node_modules[\\/]/,
        use: {
          loader: 'babel-loader',
        },
      },
    ]
  }
}

This will tell webpack that when it encounters .js or .jsx files to use Babel to transform the code. We use the exclude property to make sure Babel doesn't try to transform JavaScript files in our node_modules directory. Those are third-party dependencies that should already have been taken care of by their creators.

Next, we'll add one more dependency for a Babel preset:

yarn add --dev @babel/preset-env

And then we'll create a .babelrc file where we can do other Babel configuration as needed. We'll keep our file pretty simple and just specify the Babel preset that we want to use:

{
  "presets": ["@babel/preset-env"]
}

And finally, let's write some ES6 code in our ./src/index.js file:

import './index.css'

const p = document.createElement('p')
p.textContent = 'Hello from webpack!'
document.body.appendChild(p)

const p2 = document.createElement('p')
const numbers1 = [1, 2, 3, 4, 5, 6]
const numbers2 = [7, 8, 9, 10]
const numbers3 = [...numbers1, ...numbers2]
p2.textContent = numbers3.join(' ')
document.body.appendChild(p2)

This is a really trivial example, but we're using the spread operator here to concatenate two arrays.

Now, if we kill our running process and run yarn start again, we should see this in the browser:

Image Demo app output 7 - adds numbers

Great! Everything is working nicely.

Temporarily Missing Styles

If you disable the cache in your browser and reload the page for our demo app, you may notice a slight blip in which the page appears with just the un-styled HTML, and then the page background turns pink and the text turns white as the styles are applied.

This behavior results from how style-loader works. As mentioned above, style-loader takes CSS and places it in a style tag in your HTML. Because of that, there's a brief period of time in which the style tag hasn't been appended yet!

Now, this is OK for a development environment, but we definitely wouldn't want this kind of behavior occurring in production. Let's fix that.

MiniCssExtractPlugin

Rather than injecting CSS into our HTML as style tags, we can use the MiniCssExtractPlugin to generate separate CSS files for us. We'll use this in our production config while still just using style-loader in our development config.

First, let's install the dependency in our project:

yarn add --dev mini-css-extract-plugin

Now in our webpack.config.common.js file let's remove the CSS rule since we'll be handling this differently in development and production. We're left with this in our shared config:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /[\\/]node_modules[\\/]/,
        use: {
          loader: 'babel-loader',
        },
      },
    ]
  }
}

Now, in our webpack.config.dev.js file, let's add back in style-loader and css-loader that we just removed from our shared config:

const merge = require('webpack-merge')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'development',
  devtool: 'inline-source-map',
  devServer: {
    contentBase: './dist',
  },
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      },
    ]
  }
})

And finally, in our webpack.config.prod.js file, let's add in our new mini-css-extract-plugin:

const merge = require('webpack-merge')
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'production',
  devtool: 'source-map',
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css',
    }),
  ]
})

This one is a little different because it actually is both a plugin and a loader, so it goes in the module rules and in the plugins sections.

Also note that we use the square brackets in our file name to dynamically set the name to the original source file's name and also include the contenthash, which is a hash (an alphanumeric string) that represents the file's contents.

Now if you run yarn build this time to generate the production build, you should get some output in your terminal that looks like this:

Webpack production build output Webpack production build output

Note that it actually generates a CSS file now, and the content hash is included in the file name.

Alright, problem solved! No more blip when the page loads in production since we have the styles included as a link tag to an actual CSS file.

Cache Busting

Since we've included the content hash in the generated CSS file, now is a good time to talk about cache busting. Why, you ask, would we want the content hash included in our file names? To help the browser understand when a file has changed!

Your browser tries to be helpful by caching files it has seen before. For example, if you've visited a website, and your browser had to download assets like JavaScript, CSS, or image files, your browser may cache those files so that it doesn't have to request them from the server again.

This means that if you visit the site again, your browser can use the cached files instead of requesting them again, so you get a faster page load time and a better experience.

So, what's the problem here? Imagine if we had a file called main.js used in our app. Then, a user visits your app and their browser caches the main.js file.

Now, at some later point in time, you've released new code for your app. The contents of the main.js file have changed. But, when this same user visits your app again, the browser sees that it needs a main.js file, notes that it has a cached main.js file, and just uses the cached version. The user doesn't get your new code!

To solve this problem, a common practice is to include the content hash in each file's name. As discussed earlier, the content hash is a string representation of the file's contents. If the file's contents don't change, the content hash doesn't change. But, if the file's contents do change, then the content hash also changes.

Because the file name will now change when the code changes, the browser will download the new file since it won't have that specific file name in its cache.

Including the Content Hash

To include the content hash in our JavaScript file names, we'll modify just one line of code in our webpack.config.common.js file. This line:

filename: 'main.js'

Will change to this line:

filename: '[name].[contenthash].js'

So that the entire file looks like this:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: '[name].[contenthash].js', // this line is the only difference
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /[\\/]node_modules[\\/]/,
        use: {
          loader: 'babel-loader',
        },
      },
    ]
  }
}

Now if you run yarn build, you'll see that both your JavaScript and your CSS have content hashes included:

Webpack production build output with content hashes included Webpack production build output with content hashes included

If you run yarn build again and compare your new output to your old output, you'll notice that the content hashes are exactly the same both times.

But, if you edit your ./src/index.js file in any way and then run yarn build again, you'll get a new content hash because the content has changed! Try it!

Minifying CSS

Last but not least, we may want to minify our CSS. We're already minifying our JavaScript for the production build, but we're not minifying our CSS yet. Let's do that.

We can minimize our CSS by using the optimize-css-assets-webpack-plugin. Let's install that dependency now:

yarn add --dev optimize-css-assets-webpack-plugin

Now we can add that to an optimization section of our webpack.config.prod.js file:

const merge = require('webpack-merge')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const OptimizeCssAssetsPlugin = require('optimize-css-assets-webpack-plugin')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'production',
  devtool: 'source-map',
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css',
    }),
  ],
  optimization: {
    minimizer: [
      new OptimizeCssAssetsPlugin({
        cssProcessorOptions: {
          map: {
            inline: false,
            annotation: true,
          },
        },
      }),
    ],
  },
})

Now if we run yarn build and then check out the contents of our dist directory, we can see that the resulting CSS is minified. Nice!

body{background:#ff1493;color:#fff}
/*# sourceMappingURL=main.66e0d6aeae6f3c6fb895.css.map */

But wait! If we look at our resulting JavaScript file, it's not minified! Hmmm. It was minified before, so what happened here?

The issue is that we're now manually configuring the optimization minimizer section of our webpack config. When that section isn't in the webpack config file, webpack defaults to using its own minimizer preferences, which includes minifying JavaScript when the mode is set to production.

Since we're now overriding those defaults by adding in our preferences for minifying CSS assets, we'll need to also explicitly include instructions for how we want webpack to minify JavaScript assets.

TerserWebpackPlugin

We can minify our JavaScript files using the TerserWebpackPlugin. Let's start by installing that dependency:

yarn add --dev terser-webpack-plugin

Then, in our webpack.config.prod.js file, let's add the terser-webpack-plugin to our optimization minimizer settings at the bottom of the file:

const merge = require('webpack-merge')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const OptimizeCssAssetsPlugin = require('optimize-css-assets-webpack-plugin')
const TerserPlugin = require('terser-webpack-plugin')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'production',
  devtool: 'source-map',
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css',
    }),
  ],
  optimization: {
    minimizer: [
      new OptimizeCssAssetsPlugin({
        cssProcessorOptions: {
          map: {
            inline: false,
            annotation: true,
          },
        },
      }),
      new TerserPlugin({
        // Use multi-process parallel running to improve the build speed
        // Default number of concurrent runs: os.cpus().length - 1
        parallel: true,
        // Enable file caching
        cache: true,
        sourceMap: true,
      }),
    ],
  },
})

Now if we run yarn build and look at the output in the dist directory, we should see that both our CSS files and our JavaScript files are minified. There we go!

Wrapping Up

If you've followed along this far, I commend you!

Image _Photo by [Unsplash](https://unsplash.com/@katya?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Katya Austin / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Let's review what we've learned so far:

  • Webpack is a build tool for asset bundling and dependency management.
  • Webpack can be configured by a config file.
  • Plugins modify and extend the webpack build process.
  • Loaders instruct webpack how to handle different file types.
  • The clean-webpack-plugin can be used to remove old build artifacts from the dist directory.
  • The html-webpack-plugin helps manage the HTML file, including injecting JavaScript into the file via script tags.
  • webpack-dev-server creates a dev server to make local development easier.
  • It's helpful to have separate webpack configs for development and production. You can share and merge config files using the webpack-merge plugin.
  • We can handle styling our app by including loaders like css-loader, style-loader, sass-loader, less-loader, and the mini-css-extract-plugin (which functions as both a plugin and a loader).
  • We can include new JavaScript syntax and features by using Babel and babel-loader.
  • We can include content hashes in our file names to help with cache busting and managing new versions of our released code.
  • We can minify our CSS with the optimize-css-assets-webpack-plugin.
  • We can minify our JavaScript with the terser-webpack-plugin.

What's Next?

Image _Photo by [Unsplash](https://unsplash.com/@tomparkes?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Tom Parkes / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Throughout this article, we've created a pretty respectable webpack config. All of these techniques we've discussed are industry standards and are common to use in enterprise-level projects.

But there's still more! Other advanced webpack topics include code splitting, lazy loading, tree shaking, and more!

If you're interested in exploring webpack more on your own, I'd highly recommend reading through the official webpack guides.

Again, all of the code we've gone through in this tutorial can be found in GitHub. The starting point is found here, and the finished result is found here.

Thanks for reading, and happy coding!

]]> <![CDATA[ Introducing Packem: a super fast experimental bundler written in Rust ]]> https://www.freecodecamp.org/news/introducing-packem-a-super-fast-experimental-bundler-written-in-rust-e981af875517/ 66c3584939357f94469765ac Wed, 15 May 2019 16:36:27 +0000 By Bukhari Muhammad

Packem is an experimental precompiled JavaScript module bundler primarily implemented in Rust. It can also handle a variety of other file types like YAML/TOML, fragment shader files and a lot more. Checkout the website or the GitHub page to quickly get started.

Image Packem’s logo. Always soothes me.

Packem resolves a module’s dependencies and rehydrates them into a module graph, a flat list containing module interfaces which are essentially references to in-memory heap-based mutable data structures containing special metadata of a module in the module graph.

Most of the business logic is abstracted into Rust using FFI bindings to enable low level interactions between both ends. The Rusty binaries are available as precompiled Node C/C++ addons in Packem’s repo. A cloud-based CI is used to run a few scripts with pre-gyp installations, yielding OS-specific binaries with support for later Node versions (8, 9, 10).

This layer of Packem’s core is what is referred to as the Logical Context (LC). All the other operations that are not explicitly prioritized are regressed into Node’s general runtime, which in Packem’s terms is the Runtime Context (RC). Read more on contexts here.

Theoretically, the module graph is kept flat to avoid common pitfalls that would lead to unnecessary traversals if a tree was used in place. This allows the RC to keep track of cases such as deep circular dependencies or heavily nested dynamic imports (code splitting), amongst others, appropriately with minimum performance implications or side effects as possible.

Image An overview of the bundling cycle from contexts.

More details can be found at Packem’s README.md.

I’ve been having this idea in mind but never planned to execute it until I joined forces with Saddam M. It has really been in my interest to see module bundling as a concept safe for anyone to learn, understand and implement. Having people struggle with configurations, documentation and plugins was extremely horrendous and I’d like to take the chance to change that. With you. With Packem.

Quick history

I took some time to exhaust most of the bundlers written in a non-JavaScript environment. I found out that most of them forgot that they’re supposed to be a bundler and not a C/C++ library from the dark ‘ol 19s.

What I wanted was a bundler that does most of the heavy-lifting in a close-to-the-metal language for the user without requiring any interaction with its internals. Then I found Rust. A smart and concise systems language that shows off some laudable features like a fearless concurrency model, type safety, and more! I would expect as much from using C/C++ but I’d rather stick with Rust since it’s pretty straightforward when it comes to memory management.

Why another bundler?

So what’s the take here? Why do we need another build tool since we already have amazing ones like webpack, Parcel, Rollup, etc? I’ll take you along with a few reasons why. Perhaps you might have your own interests in having your development and production build times reduced heavily.

It’s 2019, we don’t need slow tools no more

Even though Packem is faster than webpack 4, it is more than twice as fast as Parcel (with multicore compilation). In a benchmark test, we bundled Lodash v4.17.1 with both Packem and Parcel and this was the result:

Never take any benches at face value. You can test it out for yourself here.

The reason why I didn’t bother benchmarking Parcel against webpack was because webpack 4 is profoundly faster than Parcel. I proved this fact by using Sean T. Larkin’s own benches and a thread to it on Twitter can be found here.

Because we can. Anyone can, right?

Of course, what will make the most sense, is because we can. We had the idea of having faster bundle times with a Rusty interface either with FFI or WASM (was still unsure by then). FFI was more reasonable as far as speed and DX was concerned, so we went with having Packem implemented in Rust FFI bindings.

We experienced a few thread-related issues so we didn’t make much use of the available resources. As a result we used multiple node child processes (with node-worker-farm), the same technique Parcel uses for multicore compilation, but for larger module graphs since it adds a significant startup time on top of Node’s uptime when used with smaller module graphs.

Configuration style

This was a tricky part. There were a lot of questions that needed a good answer to make up to picking the right configuration style. Static or dynamic? JSON/YAML/TOML? Our choice was based entirely on whether we needed Packem to:

  1. Have a neater configuration style, and
  2. Be agnostic of other custom user configurations like .babelrc or package.json.

Bottomline, we proceeded with a static configuration style since we found it to be exactly what we needed. Something that could declaratively tell Packem how to manage the bundle cycle. All the limits to having a static configuration were made clear.

Another aspect of interest was the type of file we should use for the configuration. JSON that is more common to an overwhelming majority of JavaScript developers or YAML/TOML/XML-style which are less common but have their own advantage(s). A suggestion was still made for JSON support (#5).

JSON just didn’t cut out because of all the unnecessary string quotes, curly & block braces, which makes sense since it’s a data interchanging format. An XML-ish approach deserves no respect with regards to being used as a configuration format since it makes things worse than JSON as far as unnecessary characters are concerned. TOML introduced a lot of new lines, and debugging nested options didn’t appear to be eye-appealing since we knew that Packem plugins could get really nesty.

The final winner was YAML! It was able to pass through all aspects of being a proper configuration format (for Packem at least). It:

  1. Makes configuration painless.
  2. Uses an elegant approach.
  3. Is still familiar to the JavaScript eye
  4. Was designed specifically for this use-case (configurations).

Here’s an example of a typical Packem configuration (packem.config.yml). Check for yourself and think about writing the same content in a JSON/TOML/XML-ish style.

FYI, only the first two options are necessary! ?

Extending Packem

This feature is not yet implemented.

Sometimes we might need to use a feature that doesn’t yet exist, might not be implemented in Packem or is very specific to our project. For that case, you’d have two ways of solving your needs:

  1. Create a Packem plugin for your use case (which is the recommended option).
  2. Build a custom RC on top of Packem’s binaries.

Using Rust gives us the chance to reform the LC into other binary formats, such as WebAssembly, which will enable Packem to exhibit multiple compile targets:

  1. A NAPI-based C/C++ addon with platform-specific binaries required by Packem’s default RC.
  2. A WebAssembly-based binary that is cross-platform and injected into the RC.
  3. Packem’s default standalone which uses WebAssembly with a browser-compatible implementation of the RC.

The last two are not yet on the radar since internal refactorings are still being sorted out.

The advanced guide is soon expected to show you how to build a custom build tool using Packem’s binaries to fit your own needs in case you need to use Packem outside the browser and Node environments. These binaries complete the entire graph generation, and duplicate filtering and other graph-related aspects. This means you can use your custom serializer, file watcher, plugin system, etc. It is much like how you can build your custom renderer over OpenGL.

  1. You can still embrace Packem’s plugin system since it will allow you to integrate Packem’s ecosystem of plugins with your custom bundler.
  2. If you’re uncertain whether or not you would need to build a custom bundler, know that you wouldn’t always need to. Please try filing an issue first.
  3. It is a guarantee that these binaries will speed up your workflow depending on your specific use case(s).

Current state

  • ✂ Code Splitting for development and production modes.
  • ? Improved CLI (— verbose) for better information on bundling cycle.
  • ? Module Interfaces to allow easy manipulation of the module graph.
  • ✔ Proper priority. Native functionalities fit perfectly into the LC. This means there is greater chances of speedy builds.
  • ? Export NativeUtils for external usage of native functionalities including generateModuleGraph which reruns the process of generating a module graph. It is heavy but still useful in cases where you’d need a clone of the current active module graph. Using it means doubling the build time, so use it with care.

What’s next?

These are the features we’re hoping to have soon in the upcoming releases. With your efforts we could get bundling done the right way. When Packem is at 1.0, we’re expecting to have full support for all the features listed below and the others mentioned in Packem’s roadmap.

  • A browser-compatible standalone of Packem with the LC in WebAssembly for closer integration with the underlying system. Axel Rauschmayer already made a feature request to have a Node-compatible version in WASM. For the record, we’ll be working on both soon.
  • Treeshaking, but advanced. Resolving named/unnamed imports and stripping dead code should be a breeze. This means you can use libraries like lodash instead of lodash-es without worrying whether your code will be elided or not.
  • Auto Config. Like Zero Config, but defaults-oriented for extra flexibility.
  • Advanced CLI options to make development with Packem a second nature.
  • Better error reporting.
  • More environment targets. Packem can only bundle for the browser as of now. Eventually, we expect to support Node CJS and other formats as well.
  • More plugins. We need more plugins! Packem has a set of common plugins to get you started quicker. But to grow a community, we’ll need a great ecosystem of plugins. Check the common plugins available or the plugins section on the site to start developing a plugin right away.
  • And much more…

Resources

Packem hasn’t reach 1.0 yet. If you have found Packem to be interesting at all to you, try contributing to Packem itself by creating plugins, updating the documentation, supporting us financially, representing Packem at conferences or any other means. We appreciate your efforts!

Happy bundling! ???

]]>