<![CDATA[ webpack - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ webpack - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ Eleventy Fri, 29 May 2026 16:31:53 +0000 60 <![CDATA[ The JavaScript Modules Handbook – Complete Guide to ES Modules and Module Bundlers ]]> https://www.freecodecamp.org/news/javascript-es-modules-and-module-bundlers/ 66ba0df4052fa53219e0a365 Wed, 11 May 2022 23:06:42 +0000 Modules and Module Bundlers are essential components of modern web development. But understanding how they work can quickly become overwhelming.

This article will show you all you need to know about ES Modules and Module Bundlers in plain English.

Table of Contents

  1. What Exactly Is a JavaScript Module?
  2. Why Use Modules?
  3. Common Types of Module Systems in JavaScript
  4. How to Convert a JavaScript File into a Module
  5. How to Use an ES Module
  6. How to Export a Module's Code
  7. How to Import Exported Code
  8. How to Use a Module's Imported Code
  9. How to Rename Exports and Imports in ES Modules
  10. Why Rename a Module's Code?
  11. How to Rename Multiple Exports in an ES Module
  12. How to Rename Multiple Imports in an ES Module
  13. How to Import All Exportable Items from an ES Module in One Go
  14. How to Export Anonymously to an ES Module
  15. What Exactly Is an Aggregator File?
  16. Project: How to Use an Aggregator File
  17. How to Use the import() Syntax to Load a Module Dynamically
  18. What Exactly Is import.meta in ES Modules?
  19. Quick Review of Modules So Far
  20. What Is a Module Bundler?
  21. Why Do You Need a Module Bundler?
  22. How Does a Module Bundler Work?
  23. How to Use Webpack
  24. How to Make Webpack Auto-Generate Your App's HTML File
  25. How to Make HtmlWebpackPlugin Use Your Source File as a Template to Auto-Generate a New HTML Page
  26. Important Stuff to Know about Updating Your App
  27. How to Rerun Webpack Automatically
  28. How to Reload the Browser Automatically
  29. What Exactly Is Webpack's Configuration File?
  30. Common Webpack Configuration Options
  31. Overview

So, without any further ado, let's get started with modules.

What Exactly Is a JavaScript Module?

A JavaScript module is a file that allows you to export its code. This allows other JavaScript files to import and use the exported code as their dependencies.

Specifically, a module is simply a JavaScript file that allows you to share its code with other files within your project (or with the world through package managers like Yarn and NPM).

Why Use Modules?

In its early days, people used JavaScript mainly for trivial scripting tasks like providing bits and pieces of interactivity to web pages where needed. In other words, developers predominately used JavaScript to write small scripts—not large ones.

Today, however, JavaScript has grown into a vast scripting tool capable of doing a lot more than just making web pages interactive.

It is now the norm to have large JavaScript code used for diverse functions like server-side website development, game development, and mobile app development.

Since JavaScript can be used for virtually any programming task, a need arose to share scripts between a project's files and the world.

So the JavaScript community developed the module system to allow developers to share their scripts on demand.

Common Types of Module Systems in JavaScript

Below are some of the popular module systems in JavaScript:

Note: ES modules are sometimes called "JS modules" or "ECMAScript modules".

Amongst the module systems listed above, the ES module system is the official standard for JavaScript.

The remaining three (AMD, CommonJS, and UMD) were created by various developers when JavaScript did not have a standardized module system.

However, since ES module's appearance in the 2015 ECMAScript standard, the previous module systems have gradually become part of JavaScript's history.

Therefore, this article will focus on showing you how ES modules work.

First, though, it is essential to know how to convert a JavaScript file into a module. So, let's discuss that below.

How to Convert a JavaScript File into a Module

To convert a JavaScript file to an ES module, do the following:

Step 1: Create a project directory

Create a project folder—where this project's HTML and JavaScript files will reside.

Step 2: Create your code files

Create the following files inside your project folder:

  1. index.html
  2. index.js

Step 3: Add your JavaScript file to your HTML document

Open your index.html file and replicate the code below:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body>
    <h1>ES Module Tutorial</h1>

    <!-- Add the "index.js" JavaScript file to this HTML document -->
    <script type="module" src="index.js"></script>
  </body>
</html>

In the HTML snippet above, we used the <script>'s type="module" attribute to convert the index.js JavaScript file to an ES module.

So, now that we know how to convert a JavaScript file into a module, let's see how to use one.

How to Use an ES Module

Follow the steps below to learn how to use an ES module.

Step 1: Create a project directory

Create a project folder—where this project's HTML and module files will reside.

Step 2: Create your code files

Create the following files inside your project folder:

  1. index.html
  2. module-1.js
  3. module-2.js

Step 3: Add the modules to your HTML document

Open your index.html file and replicate the code below:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body>
    <h1>ES Module Tutorial</h1>
    <h2>Check the console</h2>

    <script type="module" src="module-1.js"></script>
    <script type="module" src="module-2.js"></script>
  </body>
</html>

Here are the main things we did in the HTML snippet above:

  1. We added the two JavaScript files to our HTML document.
  2. We used the type="module" attribute to convert the regular JavaScript files to ES module files.

Note that JavaScript defers ES modules automatically. So, you do not need to use a defer attribute in your module's <script> element.

Also, the computer will execute a module only once—regardless of the number of <script> tags you use to reference it.

Step 4: View your app

Open your index.html file in any browser to see the current state of your app.

Open your HTML file in your browser - Modules Tutorial Opening an index.html file in a Chrome browser

Once opened, if you inspect your browser's console, you will see some error messages.

CORS policy error in the browser's console - Modules Tutorial Inspecting a Chrome browser's console

The browser threw a CORS policy error because ES modules only work through http:// and https:// URLs—not locally via a file:// URL.

In other words, since our HTML file contains two ES modules, we need to load the document via an http:// scheme.

The two typical ways to load an HTML document via an http:// scheme are:

  • By using a Local Server, or
  • Through the use of a Module Bundler

We will discuss Module Bundlers in detail later on in this article. For now, though, let's see how to use a local server to load the index.html file via an http:// scheme.

How to run an HTML file through a local server

The steps below will show you how to use a VS Code local server extension to run your HTML file.

Note: Suppose your code editor is Atom or Sublime Text. In that case, follow the links below to learn how to install a local server plugin.

1. Add your project folder to VSCode's workspace

Add your project's folder to VSCode's workspace Adding a project folder to VSCode's workspace

2. Install a local server (Live Server by Ritwick Dey)

Install the Live Server by Ritwick Dey Installing the VSCode Live Server by Ritwick Dey

3. Open your HTML file in the code editor

Open your HTML file in your code editor Opening HTML file in VSCode editor

4. Use Live Server to run the HTML file in your default browser

Run your HTML File with Live Server - Modules Tutorial Opening the project's HTML file with Live Server

Your app should now load with the http:// scheme—without any CORS error in your browser's console.

Some things to note:

  • Suppose you did not add your project folder to VSCode's workspace (step 1). In that case, the Live Server might not load your file correctly.
  • Live Server will auto-reload your browser whenever you save any changes to your HTML file.
  • Suppose you wish to stop the Live Server. In that case, right-click on the HTML editor page and click on "Stop Live Server".
  • JavaScript modules operate in strict mode by default. As such, you must abide by JavaScript's strict syntax rules. Otherwise, your program might malfunction.

So, now that you've converted your JavaScript file to an ES module, you can begin to use the export and import keywords to share your modules' code. Let's discuss how below.

How to Export a Module's Code

There are two equivalent ways to export a module's item.

  1. Place an export keyword before your code
  2. Create an export statement

Let's discuss both ways below.

How to share a module's code by placing an export keyword before the code

One way to export an item is to place an export keyword before the code you wish to share with other modules.

For instance, open your module-1.js file and replicate the code below:

// module-1.js

// Export the "bestClub" variable:
export const bestClub = "Your Club";

You can see how we place the export keyword before the const variable statement in the snippet above.

We prepended the const variable with the export keyword to tell the computer to share the bestClub variable with other modules that request it.

Note: The export keyword highlights the code you wish to share with other modules.

Here's another example:

// Export the "multiply" function:
export function multiply(x, y) {
  return x * y;
}

The statement above instructs the computer to export multiply() to the modules that request it.

Let's now see the second way to export a module's code.

How to share a module's code by creating an export statement

An alternate way to share a module's code is to use the export keyword as a standalone statement. You can do so by prepending a single export keyword to a block ({...}) of comma-separated names of code you wish to share.

Here's an example:

// Create a variable named "bestClub":
const bestClub = "Your Club";

// Create a function named "multiply":
function multiply(x, y) {
  return x * y;
}

// Create an array named "fruits":
const fruits = ["Mango", "Apple", "Orange", "Lemon"];

// Export the three statements above:
export { bestClub, multiply, fruits };

The snippet above used an export statement to indicate that the computer can share bestClub, multiply, and fruits with other modules that request any of them.

Keep in mind that export works only as a top-level item. So, it would not work in a function, for example.

Therefore, the snippet below will throw an error because we used the export keyword inside the function.

function wrong() {
  export let bestClub = "Your Club";
  return bestClub;
}

Note:

  • The export keyword works only inside modules—not inside regular JavaScript programs.
  • JavaScript hoists export statements. So, you can define them anywhere in your module.
  • Exported modules operate in strict mode by default—regardless of whether you specified the strict statement.

Let's now see how to import the exported code.

How to Import Exported Code

To import exported code, use ES module's import statement.

For instance, open your module-2.js file and replicate the code below:

// module-2.js

import { bestClub } from "./module-1.js";

In the snippet above, we used an import statement to bring in the bestClub variable from the module-1.js file.

So, module-2.js is a top-level module because it contains another script.

On the other hand, module-1.js is a submodule because it is a script used inside another file.

Note:

  • We use the import statement to import items from other modules.
  • It is mandatory to wrap your named exports in curly braces while importing them.

Keep in mind that an import statement can only get another module's code if exported with the export keyword.

For instance, the import statement below will import the bestClub, multiply, and fruits items if they got marked for exportation in the module-1.js file.

// Import three items from the module-1.js file:
import { bestClub, multiply, fruits } from "./module-1.js";

Suppose you did not use the export keyword to mark the three items as exportable features. In that case, the import statement will throw an Uncaught SyntaxError.

Note:

  • "Module specifier" and the "import specifier" are other names people call the "./module-1.js" file path string in the snippet above.
  • The dot (.) mark in the "./module-1.js" module specifier means "same directory". In other words, the dot mark tells the computer to find the module-1.js file in the same folder where the current module is.
  • The current module referred to in the snippet above is the file where the import statement got defined.

An alternative to the import specifier's dot (.) syntax is to write out the entire relative path to a module's location.

Here's an example:

// Import three items from the module-1.js file:
import { bestClub, multiply, fruits } from "/codesweetly/blog/notes/modular-javascript/es-modules/module-1.js";

You can see how long the import statement above is. We often use the dot syntax because of its short and portable length.

Suppose you choose to use the dot syntax. In that case, keep in mind that some module systems (such as Node.js and module bundlers) permit you to omit the dot mark and the file extension like so:

// Import three items from the module-1.js file:
import { bestClub, multiply, fruits } from "module-1";

However, other module systems, such as ES modules, do not permit such omissions.

Note:

  • A module specifier with no dot mark and file extension is called a "bare" module specifier.
  • A module's imported item is a read-only view of the exported feature. So, you can modify the code only inside the module that exported it—not in the module that imported it.
  • JavaScript imports a module's code as live binding. So, suppose you update the imported code's value in the exportation module. In that case, your changes will also reflect in the importation module.

Let's now discuss how to use the imported code.

How to Use a Module's Imported Code

Once you've imported your code, you can use it as if it was defined in the module into which you've imported it.

Here's an example:

// module-2.js

import { bestClub } from "./module-1.js";

const myBestClub = bestClub + " " + "is my best club.";

console.log(myBestClub);

Try it on StackBlitz

Note:

  • The import keyword works only inside modules—not inside regular JavaScript programs.
  • An imported module's features are not available in the global scope. Therefore, you can access imported items only in the script you have imported them into—not in other places like the JavaScript console.
  • JavaScript hoists import statements. So, you can define them anywhere in your module.
  • Imported modules operate in strict mode by default—regardless of whether you specified the strict statement.

So, now that we know how to use an ES module, let's discuss how to rename the code you wish to export (or import).

How to Rename Exports and Imports in ES Modules

Suppose you wish to rename the code you are exporting (or importing). In such a case, use the as keyword.

Here's an example:

// module-1.js

// Create a variable named "bestClub":
const bestClub = "Your Club";

// Export the bestClub variable as "favoriteTeam":
export { bestClub as favoriteTeam };

In the snippet above, we told the computer to export the bestClub variable as favoriteTeam.

Therefore, when importing the variable, you will use the name favoriteTeam—not bestClub.

Here's an example:

// module-2.js

import { favoriteTeam } from "./module-1.js";

const myBestClub = favoriteTeam + " " + "is my best club.";

console.log(myBestClub);

Try it on StackBlitz

We renamed the bestClub variable in the example above while exporting it. However, you can also rename it during its importation.

Here's an example:

// module-1.js

// Create a variable named "bestClub":
const bestClub = "Your Club";

// Export the bestClub variable:
export { bestClub };

// module-2.js

import { bestClub as favoriteTeam } from "./module-1.js";

const myBestClub = favoriteTeam + " " + "is my best club.";

console.log(myBestClub);

Try it on StackBlitz

The choice of whether to rename your code during exportation or importation is totally up to you.

However, many developers prefer to rename during importation because you don't always have control over a code's source file, especially when importing from a third party's module.

Why Rename a Module's Code?

Renaming can help prevent browsers from throwing errors due to name conflicts. For instance, consider these snippets:

// module-1.js

// Create a variable named "bestClub":
const bestClub = "Your Club";

// Export the bestClub variable:
export { bestClub };

// module-2.js

import { bestClub } from "./module-1.js";

const bestClub = bestClub + " " + "is my best club.";

console.log(bestClub);

Try it on StackBlitz

When you run the snippets above, the browser will throw an error similar to:

"SyntaxError: Identifier 'bestClub' has already been declared"

The browser threw the error because the imported code's name conflicts with module-2.js' bestClub variable.

However, you can rectify the error by simply renaming the imported code like so:

// module-2.js

import { bestClub as favoriteTeam } from "./module-1.js";

const bestClub = favoriteTeam + " " + "is my best club.";

console.log(bestClub);

Keep in mind that you can also rename multiple exports. Let's see how below.

How to Rename Multiple Exports in an ES Module

You can rename multiple exports by separating each as statement with a comma.

Here's an example:

// module-1.js

const bestClub = "Your Club";
const fruits = ["Grape", "Apple", "Pineapple", "Lemon"];

function multiply(x, y) {
  return x * y;
}

// Export the three statements above:
export { 
  bestClub as favoriteTeam, 
  fruits as crops, 
  multiply as product 
};

// module-2.js

import { favoriteTeam, crops, product } from "./module-1.js";

const bestClub = `I bought ${product(2, 11)} ${crops[2]}s at ${favoriteTeam}.`;

console.log(bestClub);

Try it on StackBlitz

You can also rename multiple imports. Let's see how.

How to Rename Multiple Imports in an ES Module

You can rename multiple imports by separating each as statement with a comma.

Here's an example:

// module-1.js

const bestClub = "Your Club";
const fruits = ["Grape", "Apple", "Pineapple", "Lemon"];
function multiply(x, y) {
  return x * y;
}

// Export the three statements above:
export { bestClub, fruits, multiply };

// module-2.js

import { 
  bestClub as favoriteTeam, 
  fruits as crops, 
  multiply as product 
} from "./module-1.js";

const bestClub = `I bought ${product(2, 11)} ${crops[2]}s at ${favoriteTeam}.`;

console.log(bestClub);

Try it on StackBlitz

Suppose you wish to import all exportable content from module-1.js without specifying each import's name. How can you do this? Let's find out.

How to Import All Exportable Items from an ES Module in One Go

Suppose you wish to import all exportable items from a specific module without specifying each import's name. In such a case, use the import * as syntax to bring in the items through a module object.

Here's an example:

// Import all exportable features from the "countries.js" module:
import * as allCountries from "./countries.js";

The statement above instructs the computer to import all exportable content of the ./countries.js module and encase the imports in a module object named allCountries.

After the importation, you can use the imported items just as before. However, you now need to access them through the module object's name.

Here's an example:

// module-1.js

const bestClub = "Your Club";
const fruits = ["Grape", "Apple", "Pineapple", "Lemon"];
function multiply(x, y) {
  return x * y;
}

// Export the three statements above:
export { bestClub, fruits, multiply };

// module-2.js

import * as firstModule from "./module-1.js";

const bestClub = `I bought ${firstModule.multiply(2, 11)} ${firstModule.fruits[2]}s at ${firstModule.bestClub}.`;

console.log(bestClub);

Try it on StackBlitz

So, what if you prefer to export a module's content anonymously? Let's discuss the technique you can use.

How to Export Anonymously to an ES Module

So far, we have exported items by explicitly stating the name of the specific code we wish to share—for instance, export { bestClub }.

Such exportation technique is called the named export.

You can also export anonymously by using the default export technique. But what exactly is a default export? Let's find out.

What Exactly Is a Default Export in ES Modules?

Default export is a technique developers use to export code anonymously (namelessly).

You can implement a default export by prepending the keyword default to the code you wish to export. By so doing, the computer will share the code as a default export.

In other words, the code will get exported with the special name, default—instead of its original name (if it had one).

So, during the code's importation, you will have the options to import it with the name default, a custom name of choice, or without any name.

Here's an example:

// module-1.js

const bestClub = "Your Club";

// Export the bestClub variable as a default export:
export default bestClub;

We did not use curly braces in the default export statement above because you can have only one default export in a module.

Alternatively, you can also rewrite the code above like so:

// module-1.js

// Export the string value as a default export:
export default "Your Club";

Keep in mind that you can use the default export technique to share a function, variable, string, class, or object literal.

However, you cannot prepend the export default keyword to a var, let, or const keyword.

In other words, the snippet below will throw a SyntaxError.

export default const bestClub = "Your Club";

Let's now discuss how to import a default export.

How to Import a Default Export into an ES Module

There are two equivalent ways to import a default export:

  • Use the default as syntax
  • Specify the imported code's name only

Let's discuss the two importation techniques.

How to use the default as syntax to import a default export

One way to import a default export is to use the default as syntax like so:

import { default as newName } from "./module-relative-path.js";

Here's an example:

// module-1.js

// Export the string value as a default export:
export default "Your Club";

// module-2.js

import { default as favoriteTeam } from "./module-1.js";

const bestClub = favoriteTeam + " " + "is my best club.";

console.log(bestClub);

Try it on StackBlitz

Notice that we didn't need to specify the name of the code we imported from the module-1.js file. Instead, we used the default keyword to import the code anonymously.

Afterward, we renamed the imported code as favoriteTeam.

Let's now see the second way to import a default export.

How to import a default export by specifying the imported code's name only

An alternate way to import a default export is to ignore the curly braces ({...}), the default keyword, and the as keyword.

Instead, simply specify the name you wish to use to reference the imported code like so:

import newName from "./module-relative-path.js";

Here's an example:

// module-1.js

// Export the string value as a default export:
export default "Your Club";

// module-2.js

import favoriteTeam from "./module-1.js";

const bestClub = favoriteTeam + " " + "is my best club.";

console.log(bestClub);

Try it on StackBlitz

You can see that the shortened importation technique above is neater than the previous option.

Note:

  • The export default statement makes it possible for a JavaScript module to interpolate (work reliable) with existing CommonJS and AMD module systems.
  • See the "Default exports" section of ES6 In Depth: Modules to learn more about interpolation.

Before we wrap up our discussion on ES modules, you should be aware that you can use an aggregator file to collate your project's import statements.

But what exactly is an aggregator file, I hear you ask? Let's find out below.

What Exactly Is an Aggregator File?

An aggregator file is a script used solely to import and re-export the items you've exported from other modules.

In other words, instead of congesting your top-level module with multiple import statements from various files, you can create a single parent script (the aggregator file).

The parent script's sole purpose will be to import and re-export items from other modules.

Then, in your top-level module, you can simply import any required code from the aggregator file alone—not from numerous other scripts.

By so doing, you will make your top-level module neater.

So, what exactly does all this mean? Let's see with a mini-project.

Project: How to Use an Aggregator File

Follow the steps below to learn how to use an aggregator file.

Step 1: Create a project directory

Create a project folder—where this project's HTML and module files will reside.

Step 2: Create your code files

Create the following files inside your project folder:

  1. index.html
  2. index.js
  3. preferences.js
  4. calculation.js
  5. bio.js

Step 3: Add the modules to your HTML document

Open your index.html file and replicate the code below:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body>
    <h1>How to use an aggregator file - ES Module Tutorial</h1>
    <h2>Check the console</h2>

    <script type="module" src="index.js"></script>
    <script type="module" src="preferences.js"></script>
    <script type="module" src="calculation.js"></script>
    <script type="module" src="bio.js"></script>
  </body>
</html>

Here are the main things we did in the HTML snippet above:

  1. We added the four JavaScript files to our HTML document.
  2. We used the type="module" attribute to convert the regular JavaScript files to ES module files.

Step 4: Export items from your preference module

Open your preferences.js module and export some items from it like so:

const bestFruits = ["Grape", "Apple", "Pineapple", "Lemon"];
const bestColor = "White";
const bestNumber = 111;
const bestClub = "Your Club";
const bestTime = "Now";

export { bestClub, bestFruits };

Step 5: Export items from your calculation module

Open your calculation.js module and export some items from it like so:

function add(x, y) {
  return x + y;
}

function subtract(x, y) {
  return x - y;
}

export function multiply(x, y) {
  return x * y;
}

function divide(x, y) {
  return x / y;
}

Step 6: Export items from your bio module

Open your bio.js module and export some items from it like so:

const aboutMe = {
  firstName: "Oluwatobi",
  lastName: "Sofela", 
  companyName: "CodeSweetly",
  profession: "Web Developer",
  gender: "Male",
};

export default aboutMe;

Step 7: Import the exported features

To import the exported items into your top-level module, you have two options:

  1. Import directly from the exporting modules to your top-level script.
  2. Import from an aggregator file to your top-level module.

Let's see the difference between the two options.

Import directly from the exporting modules to your top-level script

One way to import your code is to import it directly from the exporting scripts to your top-level module.

For instance, open your index.js file and import the exported content of the preferences.js, calculation.js, and bio.js modules like so:

// index.js

import { bestFruits } from "./preferences.js";
import { multiply } from "./calculation.js";
import aboutMe from "./bio.js";

const news = `All ${aboutMe.companyName}'s staff gave Tom ${multiply(7, 129)} ${bestFruits[2]}s.`;

console.log(news);

Try it on StackBlitz

You can see that we imported items directly from three exporting scripts into the index.js module.

The above importation technique works OK. However, a cleaner alternative is to use an aggregator file. Let's see how.

Import from an aggregator file to your top-level module

An alternate way to bring in your code is to import it from an aggregator file to your top-level module.

Follow the steps below to see how you can create and use an aggregator file.

1. Create the aggregator file

You can name the file aggregator.js or any other name you prefer.

Create an aggregator file - Modules Tutorial A highlight of the project's aggregator file

2. Add the aggregator script to your HTML file
<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body>
    <h1>How to use an aggregator file - ES Module Tutorial</h1>
    <h2>Check the console</h2>

    <script type="module" src="index.js"></script>
    <script type="module" src="preferences.js"></script>
    <script type="module" src="calculation.js"></script>
    <script type="module" src="bio.js"></script>
    <script type="module" src="aggregator.js"></script>
  </body>
</html>

Note the following:

  1. index.js is the top-level module because it is the file where we imported and used preferences.js, calculation.js, and bio.js.
  2. preferences.js, calculation.js, and bio.js are the submodules because they are the files we imported into the top-level module.
  3. aggregator.js is the parent module because it is the script for aggregating and re-exporting the three submodules.

Technically, you can indicate just the top-level module in your project's HTML file like so:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body>
    <h1>How to use an aggregator file - ES Module Tutorial</h1>
    <h2>Check the console</h2>

    <script type="module" src="index.js"></script>
  </body>
</html>

By so doing, you avoid cluttering your HTML page with the submodules and parent module.

Let's now see how to use the aggregator module.

3. Use the aggregator module to aggregate the submodules

Here's how to use the aggregator module to import and re-export all your project's exported items:

// aggregator.js

import { bestFruits } from "./preferences.js";
import { multiply } from "./calculation.js";
import aboutMe from "./bio.js";

export { bestFruits, multiply, aboutMe };

You can see that we used the aggregator file only to import and re-export our project's exported features.

The shorthand way to write the import/export statements above is like so:

// aggregator.js

export { bestFruits } from "./preferences.js";
export { multiply } from "./calculation.js";
export { default as aboutMe } from "./bio.js";

Keep in mind that the following syntax is invalid:

export aboutMe from "./bio.js";

In other words, whenever you use the export...from syntax to re-export a default export, make sure that you rename the re-exportation like so:

export { default as aboutMe } from "./bio.js";

Let's now see how to import the re-exported features from an aggregator file.

4. Import your exports from the aggregator file

Once you've aggregated all your submodules into the aggregator module, go to your top-level script (index.js in this case) and import the exported items.

Here's an example:

// index.js

import { bestFruits, multiply, aboutMe } from "./aggregator.js";

const news = `All ${aboutMe.companyName}'s staff gave Tom ${multiply(7, 129)} ${bestFruits[2]}s.`;

console.log(news);

Try it on StackBlitz

You see, like magic, we've cleaned up our code by replacing three import statements with a single line!

Using an aggregator file to collate your project's exports helps separate concerns and makes your top-level module neater.

Up till now, we've used the static import syntax to instruct the computer to evaluate our imported modules' code at load time.

But suppose you prefer to load your modules conditionally or on-demand. In that case, you can use the dynamic import() syntax. Let's see exactly how it works below.

How to Use the import() Syntax to Load a Module Dynamically

To load your module conditionally or on-demand, use the import() syntax like so:

import("./module/relative-path.js").then(function (module) { });

The import() syntax does two main things:

  1. It loads its module specifier argument ("./module/relative-path.js" in this case).
  2. It returns a promise object that resolves to a module object containing the import specifier's exports.

So, since the import() syntax returns a promise, you can also use the await keyword with it.

Here's an example:

const module = await import("./module/relative-path.js");

Note: Although import() resembles a function call, it is not. Instead, the import() code is a special ES modules syntax that uses parentheses (similar to the super() syntax).

Therefore, you cannot call, apply, or bind the import() syntax because it does not inherit Function.prototype's properties.

To see precisely how import() works in practice, let's update our previous project by following the steps below.

1. Update your HTML file

Open your index.html file and do the following:

  1. Update your <h1>'s content to "The Latest News".
  2. Substitute the <h2> element with an empty <p> element.
  3. Create a <button> element.

In other words, your index.html file should look like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body>
    <h1>The Latest News</h1>
    <p id="news-paragraph"></p>
    <button id="news-button">Get the News</button>

    <script type="module" src="index.js"></script>
  </body>
</html>

2. Update your index.js module

Open your index.js file and replicate the code below:

// index.js

const paragraphElement = document.getElementById("news-paragraph");
const buttonElement = document.getElementById("news-button");

async function displayNews() {
  let news = null;
  // highlight-next-line
  const aggregatorModule = await import("./aggregator.js");

  news = `All ${aggregatorModule.aboutMe.companyName}'s staff gave Tom ${aggregatorModule.multiply(7, 129)} ${aggregatorModule.bestFruits[2]}s.`;

  paragraphElement.innerText = news;
}

buttonElement.addEventListener("click", displayNews);

Try it on StackBlitz

You can see how we used the import() method to load the aggregator module on demand (when a user clicks the button)—rather than upfront.

Although dynamic importation can improve your program's initial load-time performance, it's best to use it only when needed.

Note: The import() method does not require its argument to have a <script> of type="module". Therefore, you can use it in a regular JavaScript file.

Now, suppose you wish to get metadata about your current module. In that case, you can use the import.meta syntax.

What Exactly Is import.meta in ES Modules?

The import.meta code is an object containing information about your current module.

Here's an example:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body>
    <h1>About import.meta</h1>
    <h2>Check the console ⬇⬇⬇</h2>

    <script type="module">
      console.log(import.meta);
      console.log(import.meta.url);
    </script>
  </body>
</html>

Try it on StackBlitz

The import.meta code in the snippet above will return some information about the module in which it got used.

Quick Review of Modules So Far

We've learned that a JavaScript module is simply a file with an add-on capability to share its code with other modules within a project—or with the world through package managers like Yarn and NPM.

We also used a local server to load our HTML documents via an http:// scheme—which made browsers load our apps without throwing any CORS error.

However, live servers are limited to local developments and testing purposes.

In other words, you cannot use a live server in production to serve your HTML document via an http:// scheme. Instead, it would be best if you used a module bundler.

But what exactly is a module bundler, I hear you ask? Let's find out below.

What Is a Module Bundler?

A module bundler is a tool developers use to bundle an app's modules and dependencies into a single browser-compatible JavaScript file.

Why Do You Need a Module Bundler?

Module bundlers allow browsers to access the file you specified in a require() or import statement.

In other words, suppose a browser runs a JavaScript file with a require("./node_module/test/sample/app.js") statement. In such a case, the browser will throw an error that says Uncaught ReferenceError: require is not defined.

The computer will throw such an error because browsers cannot access files specified in a JavaScript program.

However, you can use a module bundler to create a new JavaScript file containing code browsers can read.

How Does a Module Bundler Work?

A module bundler does its bundling work as follows:

First, it creates an output script file

The module bundler will first create an "output script file" in your project's dist folder.

Note:

  • The bundler uses the output script file to save the bundled code.
  • An output file is the compiled version of an entry file. In other words, an output script file refers to the JavaScript file a bundler generates automatically for your project.
  • An entry point is a file that a bundler uses to start building a dependency graph of all the project's modules it needs to combine into a single browser-compatible module.
  • An entry point is the most critical file of a build step that links (directly or indirectly) to every other module in a project.

Next, the module bundler compiles your code

Secondly, the bundler will check the build step's entry point for any occurrence of some require() or import statements.

Suppose the module bundler finds a require() or import statement. In such a case, the bundler will compile (combine) the content of each dependency specified in the statements with the entry point's content.

Note:

  • A build step is a process through which a module bundler builds a new browser compatible JavaScript file.
  • A build step's output file is sometimes called a distribution code. In other words, distribution code is the minified and optimized source code version.
  • A dependency is a file your script requires to work as intended. So, in import { variable } from "./path/to/module.js", module.js is the dependency file because it is a script our app depends on to function as designed.

Let's now discuss the last thing a module bundler does.

Finally, it saves the compiled code

A module bundler's last step is to save the compiled code into step 1's output script file.

As a result, step 1's script file (the build step's output) will contain the content of the entry point and its dependencies—but no require() or import statements.

Note: Typical examples of module bundlers are webpack, browserify, rollup, and parcel.

So, now that we know how a module bundler works, let's discuss how to use a popular one—Webpack.

How to Use Webpack

Follow the steps below to learn how to use Webpack to bundle your project's JavaScript file and its dependencies into a single output script file.

Step 1: Create a project directory

Create a project folder—where this project's files will reside.

Step 2: Go to the project's root folder

Using the command line, navigate to the root directory of your project like so:

cd path/to/project/root-directory

Note: A root directory is a folder containing all other files and sub-folders of a specific project.

In other words, the folder you created in step 1 is your root folder because it will house everything concerning this particular project.

Step 3: Create a package.json file

Create a package.json file in your project's root directory like so:

npm init -y

Alternatively, you can use Yarn like this:

yarn init -y

Note:

  • The -y flag instructs NPM (or Yarn) to create a default package.json file.
  • You must have Node and NPM installed on your system for the initialization code above to work. You can get both by installing the latest LTS version from the Node.js website.

Step 4: Install the Webpack module bundler

Install webpack and webpack-cli locally into your project as development dependency libraries:

npm install webpack webpack-cli --save-dev

Or, if your package manager is Yarn, run:

yarn add webpack webpack-cli --dev

Note: The webpack-cli package makes running webpack on the command line possible.

Step 5: Create your project's directories

Create a "source" code folder (./src) and a "distribution" code folder (./dist).

mkdir src dist

Note: Although src and dist are the names typically given to the source and distribution code's folders, you are free to choose any other name you prefer.

Step 6: Create your source code files

Create the following files inside the newly created source code directory:

  1. index.html
  2. index.js

Note:

  • Webpack recommends saving source code in a ./src directory and distribution code in a ./dist directory.
  • Webpack does not alter any other code apart from the require(), import, and export statements.

Step 7: Add the JavaScript file to your HTML document

Open your index.html file and replicate the code below:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body id="body">
    <h1>Module Bundler Tutorial</h1>
    <button id="button">Click Me to Change Color!</button>

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

Here are the main things we did in the HTML snippet above:

  1. We created a <h1> and <button> element.
  2. We added step 6's JavaScript file to our HTML document.

Note: When using a bundler, you do not need to add the type="module" attribute to your project's <script> element. Instead, the bundler will automatically treat all scripts containing import and export statements as modules.

Step 8: Install some dependencies

Using your text editor, install your project's dependencies locally.

For instance, here's how you can install the randomColor package as a local dependency:

npm install randomcolor --save

Note:

  • Use the npm install package-name --save command for dependencies your app needs in production.
  • Use the npm install package-name --save-dev command for dependencies your app only needs for its local development and testing purposes.

Alternatively, you can use Yarn like so:

yarn add randomcolor

Note: Use the yarn add package-name --dev command for dependencies your app only needs for its local development and testing purposes.

Step 9: Import your dependencies

Import your dependencies into your JavaScript source code with the require() method or the import statement.

For instance, here's how to use the import statement to bring in step 8's randomColor dependency into your index.js script file:

// index.js

import randomColor from "randomcolor";

The require() method equivalence of the snippet above is like so:

// index.js

const randomColor = require("randomcolor");

Note:

  • The import statement is JavaScript's native way of importing modules.
  • The require() function is the CommonJS syntax for importing modules into a script.
  • An alternative way to import your project's dependencies is to implicitly load them with your HTML document's <script> tag. However, such a technique pollutes the global scope. So, using the import or require() syntax is better.

Step 10: Use the dependencies

Use the dependencies you imported in step 9 to do as you desire.

For instance, here's how you may use the randomColor dependency:

// index.js

import randomColor from "randomcolor";

const bodyElement = document.getElementById("body");
const buttonElement = document.getElementById("button");

function changeBodyColor() {
  const color = randomColor();
  bodyElement.style.backgroundColor = color;
}

buttonElement.addEventListener("click", changeBodyColor);

In the snippet above, we told the computer that whenever a user clicks the buttonElement, it should:

  1. Invoke the changeBodyColor function.
  2. Initialize the function's color variable with randomColor's invocation output.
  3. Use the color variable's value to style the bodyElement's background color.

Let's now bundle up our entry point (the index.js file) and the randomColor dependency into a single JavaScript file.

Step 11: Start the build step

Using your terminal, create your bundle by running webpack like so:

npx webpack

After running the command above, webpack will do the following:

  1. It will use your index.js as its entry point.
  2. It will create a bundle (the output file) in your project's dist folder containing the content of the entry point and its dependencies.

Note:

  • By default, Webpack generates its bundle as a main.js file—which it will save in the distribution folder you created in step 5. However, you can change the default setting by creating a configuration file—which Webpack will use automatically. We will discuss creating and using a configuration file later in this guide.
  • NPX is Node's package runner that will automatically find and execute Webpack.

Our next step is to tell browsers to use the newly created bundle. Let's do that below.

Step 12: Refer browsers to the newly created bundle

So, now that you have created a browser-compatible bundle file, you need to tell browsers to use it instead of the index.js source code file.

Therefore, go to your HTML file and substitute the reference to your JavaScript source code with Webpack's distribution bundle.

For instance, instead of using "./index.js" in the <script> tag of your HTML file, you would use "../dist/main.js" like so:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body id="body">
    <h1>Module Bundler Tutorial</h1>
    <button id="button">Click Me to Change Color!</button>

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

Let's now see our app!

Step 13: Check your app in the browser

Open your HTML file in the browser to confirm that the browser can successfully read your app and its dependencies.

Remember that you created your HTML file manually in step 6. However, Webpack can also auto-generate one for you. Let's find out how.

How to Make Webpack Auto-Generate Your App's HTML File

Suppose your app is now outputting multiple bundles, or you've started using hashes to create unique filenames. In that case, you may find it increasingly difficult to manage your HTML file manually.

Therefore, Webpack allows you to use the HtmlWebpackPlugin to auto-generate and manage your project's index.html file.

Follow the steps below to learn how to use HtmlWebpackPlugin to auto-generate and manage your project's HTML file.

Step 1: Install HtmlWebpackPlugin

Install the HtmlWebpackPlugin like so:

npm install html-webpack-plugin --save-dev

Or, if your package manager is Yarn, use:

yarn add html-webpack-plugin --dev

Step 2: Create a configuration file

Create a Webpack configuration file in your project's root folder like so:

touch webpack.config.js

Step 3: Add the plugin to webpack's configuration

Open your webpack.config.js file and add the HtmlWebpackPlugin plugin to it like so:

// webpack.config.js

const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = { 
  plugins: [new HtmlWebpackPlugin()] 
}

Note: We will discuss how to use a configuration file later in this guide.

Step 4: Run the build step

Once you've installed and added HtmlWebpackPlug into your project, recompile your modules like so:

npx webpack

After running the build step, HtmlWebpackPlugin will do the following:

  1. It will auto-generate a new index.html file.
  2. The plugin will automatically insert the bundles that Webpack generated into the newly created HTML document.
  3. It will auto-save the new HTML file inside your project's distribution folder.

In other words, after running a build, the new HtmlWebpackPlugin()'s invocation (in the configuration file) will auto-generate a dist/index.html file with the following content:

<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Webpack App</title>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <script defer src="main.js"></script>
  </head>
  <body>
  </body>
</html>

Notice that the HTML document generated by HtmlWebpackPlugin does not contain your source file's <h1> and <button> elements.

In other words, suppose you open the dist/index.html file in the browser. In that case, the browser will open an empty HTML page.

The HtmlWebpackPlugin omitted the content of the source code's <body> element because it did not create the new file from the original document. Instead, it automatically created a brand-new HTML page that includes only the bundles Webpack generated.

However, you can also tell HtmlWebpackPlugin to use your source file as a template. Let's see how below.

How to Make HtmlWebpackPlugin Use Your Source File as a Template to Auto-Generate a New HTML Page

To make HtmlWebpackPlugin use your HTML source file as a template, do the following:

1. Update your HTML file

Open your index.html source code file and delete the <script> tag you previously used to reference Webpack's distribution bundle.

So, your HTML source code should look like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
  </head>
  <body id="body">
    <h1>Module Bundler Tutorial</h1>
    <button id="button">Click Me to Change Color!</button>
  </body>
</html>

We deleted the distribution bundle's script because HtmlWebpackPlugin will automatically insert one while it auto-generates the new HTML file.

Remember: The plugin will use your source code as a template to create the new file. Therefore, deleting the hand-coded bundle's reference helps avoid conflicting scripts.

Now, let's configure the plugin to use your source code as a template.

2. Update your configuration file

Open your project's webpack.config.js file and update HtmlWebpackPlugin's settings like so:

// webpack.config.js

const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = { 
  plugins: [new HtmlWebpackPlugin({
    template: "./src/index.html"
  })] 
}

In the configuration snippet above, we did the following:

  1. We passed an object argument containing a template property to the HtmlWebpackPlugin function.
  2. We initialized the template property with the path to our HTML source code.

So, if you now run the npx webpack command, HtmlWebpackPlugin will use ./src/index.html as a template to generate the new dist/index.html file.

Therefore, the newly created HTML distribution file will look like so:

<!doctype html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ES Module - CodeSweetly</title>
    <script defer="defer" src="main.js"></script>
  </head>
  <body id="body">
    <h1>Module Bundler Tutorial</h1>
    <button id="button">Click Me to Change Color!</button>
  </body>
</html>

Suppose an index.html file already exists in your output (dist) directory. In that case, the new one generated by HtmlWebpackPlugin will replace the existing HTML file.

3. Check your app in the browser

Open the newly generated dist/index.html file in the browser to confirm that the browser can successfully read your app and its dependencies.

Note:

  • HtmlWebpackPlugin allows you to specify how and where you want it to generate your HTML file by providing specific configuration options. For instance, new HtmlWebpackPlugin({ title: "A CodeSweetly Project" }) tells the plugin to use "A CodeSweetly Project" as the title of the generated HTML file.
  • Suppose you get an error message (for instance, ReferenceError: __webpack_base_uri__ is not defined). In that case, you likely need to update your Webpack dependency. You can do so by running npm update webpack webpack-cli on your terminal.

Important Stuff to Know about Updating Your App

Whenever you make changes to your source code, make sure you do the following for your updates to reflect in the browser:

  1. Rerun the build step.
  2. Refresh your browser.

Repeating the manual process of running the build step and refreshing your browser can be burdensome. Luckily, Webpack provides a way to automate the two tasks. Let's find out how.

How to Rerun Webpack Automatically

Suppose you wish to automate the process of rerunning the build step. In that case, you can add a watch property to your package.json's scripts field.

For instance, do the following:

1. Add watch to the scripts fields

Open your project's package.json file and add a watch property to its scripts field like so:

{
  "name": "your_package",
  "version": "1.0.0",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "watch": "webpack --progress --watch"
  }
}

The snippet above added a "watch" property—with the value "webpack --progress --watch"—to the "scripts" field of our package.json file.

2. Run the watch script

Using your terminal, invoke your package.json's watch script like so:

npm run watch

Alternatively, you can use Yarn like this:

yarn run watch

Once you've invoked the watch script, NPM will execute "webpack --progress --watch".

What is "webpack --progress --watch"?

The "webpack --progress --watch" command instructs NPM to:

  1. Run Webpack.
  2. Pass the --progress and --watch options to Webpack's configuration.

The --progress option will make NPM show the percentage progress of Webpack's compilation.

The --watch option activates Webpack's watch mode.

In other words, --watch instructs Webpack to watch and automatically recompile your modules each time you save changes to files within your dependency graph.

As an example, go to your index.js file and add a console.log statement to the changeBodyColor() function like so:

// index.js

import randomColor from "randomcolor";

const bodyElement = document.getElementById("body");
const buttonElement = document.getElementById("button");

function changeBodyColor() {
  const color = randomColor();
  bodyElement.style.backgroundColor = color;
  console.log(color);
}

buttonElement.addEventListener("click", changeBodyColor);

Afterward, save your changes. Then refresh your browser.

After the refresh, do the following:

  1. Open your browser's console.
  2. Click your app's "Click Me to Change Color!" button.

You can see that the --watch flag automatically recompiled your modules when you saved your source code's changes.

Therefore, you no longer need to run the npx webpack command manually again. Instead, the --watch flag will watch and automatically recompile your modules whenever you save changes.

Note:

  • After running npm run watch, your currently opened terminal will continue to process the watch command's activities. So, you won't be able to input any command on that terminal until you stop watch's execution. However, you can open a new terminal window to use simultaneously with the one processing watch. In other words, use one terminal to run watch and another to input commands.
  • To stop watch's execution, use ctrl + c on windows or cmd + c on mac.
  • You can rename the "watch" key (or any other scripts' key) to any other name you prefer.
  • You can ignore watching huge folders like node_modules by adding them to the watchOptions.ignored field of your project's configuration file.

So, now that we know how to automate Webpack's execution, let's discuss how to reload the browser automatically.

How to Reload the Browser Automatically

Suppose you wish to automate the process of reloading your browser. In that case, you can use Webpack's dev server package.

The following steps will show you how to configure and use the package.

Step 1: Install webpack's web server

Using your terminal, install the webpack-dev-server package like so:

npm install webpack-dev-server --save-dev

Or, if your package manager is Yarn, run:

yarn add webpack-dev-server --dev

Note: The webpack-dev-server package enables watch mode by default. Therefore, you do not need to enable a watch script manually whenever you use the dev server.

In other words, once you've decided to use Webpack's dev server, do the following:

  1. Use ctrl + c on windows or cmd + c on mac to stop watch's execution (if the script is still running).
  2. Delete the watch property you previously added to your package.json file.

Step 2: Specify your files' location

Tell the web server where it should get the files that Webpack did not generate by adding a devServer option to the configuration file you created previously:

// webpack.config.js

const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = { 
  plugins: [new HtmlWebpackPlugin({
    template: "./src/index.html"
  })],
  devServer: {
    static: "./dist"
  }
}

The configuration snippet above tells the dev server to serve contents Webpack did not build from the project's dist folder.

Note that the dev server serves files on localhost:8080 by default. However, you can specify the port you wish to use by adding a port property to the devServer option like so:

// webpack.config.js

const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = { 
  plugins: [new HtmlWebpackPlugin({
    template: "./src/index.html"
  })],
  devServer: {
    static: "./dist",
    port: 5001
  }
}

Note:

  • webpack-dev-server uses output.path's directory to serve bundled files.
    In other words, the dev server will use http://[devServer.host]:[devServer.port]/[output.publicPath]/[output.filename] to generate the bundled file's URL.
  • We will discuss how to use a configuration file later in this guide.

Let's now see how to run the dev server.

Step 3: Run the dev server

There are two ways to run the dev server.

  • Use NPX on your CLI
  • Use package.json's scripts field

Let's discuss both ways below.

How to run Webpack's dev server by using NPX on your CLI

Using the terminal, navigate to your project's root directory—where the webpack.config.js file is—then use NPX to run the dev server like this:

npx webpack serve --mode development --open

The snippet above uses NPX to do the following:

  1. Run the build step by executing Webpack.
  2. Serve the build step's output file from memory, not your hard disk.

Note:

  • The dev server requires an HTML document (usually an index.html file) to serve the build step's output.
  • The --mode development flag tells Webpack to run the build step in development mode.
  • The --open flag tells the dev server to open your default browser.

Keep in mind that the dev server does not save the build step's output file to any of your project's directories. Instead, it does the following:

  1. It keeps the build step's output files in memory (your system's RAM).
  2. It serves the output files from memory, not your system's hard drive.

Using your system's memory to build and serve the output file makes the dev server fast at serving your bundle.

However, when your app is ready for production, remember to run the npx webpack compilation command to save your bundle in your project's distribution folder—rather than in memory.

Let's now discuss the second way to run the dev server.

How to run Webpack's dev server by using package.json's scripts field

An alternate way to run the dev server is to add the "webpack serve --mode development --open" command to your package.json's scripts field like so:

{
  "name": "your_package",
  "version": "1.0.0",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "webpack serve --mode development --open"
  }
}

Afterward, you can use npm run start on your terminal to execute the webpack serve --mode development --open command.

Once you've started the dev server—via either option 1 or 2, your default browser will automatically open with your project's HTML page.

Then, anytime you save changes to your source code, the dev server will automatically reload your browser to reflect the recent updates.

Note:

  • After running npm run start, your currently opened terminal will continue to process the dev server's activities. So, you won't be able to input any command on that terminal until you stop the server. However, you can open a new terminal window while using the current one to process the server. In other words, use one terminal to run the dev server and another to input commands.
  • To stop the dev server's execution, use ctrl + c on windows or cmd + c on mac.
  • You can rename the "start" key (or any other scripts' key) to any other name you prefer.
  • Check out Webpack's documentation for more ways to configure the dev server.

Remember that we used a configuration file in step 2. Let's talk more about what the file does.

What Exactly Is Webpack's Configuration File?

Webpack's configuration file is a JavaScript file that allows you to modify or extend Webpack's default settings.

For instance, Webpack's default setting assumes your project's entry point is src/index.js.

Also, by default, Webpack will minimize, optimize, and output the result of its build step into a dist/main.js file.

However, suppose you wish to change those default settings (or add more configurations). In such a case, you would need to create a configuration file—which Webpack will use automatically.

The following steps will show you how to create and use a Webpack configuration file.

Note: You can skip steps 1 and 2 if your project already has a configuration file.

Step 1: Go to the project's root folder

Navigate to your project's root directory like so:

cd path/to/project/root-directory

Step 2: Create your project's configuration file

Create a configuration file in your project's root folder like so:

touch webpack.config.js

Step 3: Specify your configurations

Open your project's webpack.config.js file and specify the configuration options you wish to change (or add).

Here's an example:

// webpack.config.js

const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = { 
  plugins: [new HtmlWebpackPlugin()] 
};

Here's what we did in the configuration file above:

  1. We initialized the HtmlWebpackPlugin variable with the "html-webpack-plugin" package.
  2. We exported an object containing the plugins configuration we want Webpack to use.

So, whenever you run the build step, Webpack will automatically use the settings you've specified in the configuration file—rather than its default settings.

Let's now run the build step.

Step 4: Run the module bundler

Using your terminal, create your bundle by running Webpack like so:

npx webpack --config webpack.config.js

The --config webpack.config.js code used in the snippet above is optional. We used it above to illustrate that it is possible to pass a configuration of any name—which you may need for complex configurations that requires a split into multiple files.

However, Webpack will use the webpack.config.js file by default if it is present in your project's root directory.

Keep in mind that plugins is only one of the numerous options you can use in a configuration file.

Let's discuss other configuration options developers use.

Common Webpack Configuration Options

Below are popular configuration options you can use to alter (or extend) Webpack's default settings.

entry

The entry field specifies the file or files you want Webpack to use to begin the application's bundling process.

Here's an example:

// webpack.config.js

module.exports = {
  entry: "./src/index.js",
};

The snippet above instructs Webpack to start its bundling process from "./src/index.js".

Suppose you used an array (or an object) as the entry field's value. In that case, Webpack will process all the array's (or object's) items as the application's entry points.

Here's an example:

// webpack.config.js

module.exports = {
  entry: [
    "./src/index.js",
    "./src/index-two.js",
    "./src/index-three.js"
  ]
}

The code above instructs Webpack to start its bundling process from the three files specified in the entry array (that is, "./src/index.js", "./src/index-two.js", and "./src/index-three.js").

Here's another example:

// webpack.config.js

module.exports = {
  entry: {
    index: "./src/index.js",
    indexTwo: "./src/index-two.js",
    indexThree: "./src/index-three.js"
  }
}

The code above instructs Webpack to start its bundling process from the three files specified in the entry object (that is, "./src/index.js", "./src/index-two.js", and "./src/index-three.js").

Note:

  • If entry's value is a string or an array, Webpack will create a chunk (bundle)—which it will name main by default.
  • If entry's value is an object, Webpack will create one or more chunks. The specific number of chucks created will depend on the total properties of the object.
  • Supposing entry's value is an object. In that case, Webpack will use each key to name each chunk. For instance, in entry: { home: './home-module.js' }, Webpack will create a chunk (bundle) named home.

context

The context field points Webpack to the directory containing your entry files.

Here's an example:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "index.js",
  context: path.resolve(__dirname, "src")
}

The snippet above tells Webpack to locate the index.js entry file in the project's src directory.

output

The output field specifies how and where Webpack should output the bundles and assets it processed.

The three options commonly used with the output field are path, filename, and clean.

output.path

The output.path option specifies the output directory you want Webpack to place the bundled file.

Here's an example:

// webpack.config.js

const path = require("path");

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

The snippet above used the output.path option to tell Webpack to use the project's "./dist" folder as the output directory.

output.filename

The output.filename option specifies how Webpack should name each bundle it creates.

Suppose you are creating only a single bundle via one entry point. In that case, you can specify a static name as the bundle's filename.

Here's an example:

// webpack.config.js

const path = require("path");

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

The output.filename option tells Webpack to use "codesweetly.js" as the filename of the bundle created after processing "./src/index.js".

Suppose you wish to create multiple bundles through two or more entry points, code splitting, or various plugins. In such a case, it is better to dynamically generate each bundle's filename via any of Webpack's substitutions techniques.

Note: Substitutions—in Webpack—refer to using bracketed strings to create templates for filenames.

Let's now discuss the three commonly used substitution techniques.

Substitutions technique 1: Entry name

The "entry name" substitutions naming technique makes Webpack create each bundle's name by concatenating a bundle's entry point's name with a given string.

Here's an example:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: {
    home: "./src/home-module.js",
    promo: "./src/promo-module.js",
    music: "./src/music-module.js"
  },
  output: {
    filename: "[name].bundle.js",
    path: path.resolve(__dirname, "dist")
  }
}

The output.filename option tells Webpack to create each bundle's filename by concatenating each entry point's name with the ".bundle.js" string value.

So, for instance, suppose Webpack has finished processing the promo entry point (that is, "./src/promo-module.js"). In that case, the final bundle's name will be "promo.bundle.js".

Let's now discuss the second substitutions technique.

Substitutions technique 2: Internal chunk id

The "internal chunk id" substitutions naming technique makes Webpack create each bundle's name by concatenating a bundle's entry point's id with a given string.

Here's an example:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: {
    home: "./src/home-module.js",
    promo: "./src/promo-module.js",
    music: "./src/music-module.js"
  },
  output: {
    filename: "[id].bundle.js",
    path: path.resolve(__dirname, "dist")
  }
}

The output.filename option tells Webpack to create each bundle's filename by concatenating each entry point's internal chuck id with the ".bundle.js" string value.

Let's now discuss the third substitutions technique.

Substitutions technique 3: Content hash

The "content hash" substitutions naming technique makes Webpack create each bundle's name by concatenating the generated content's hashes with a given string.

Here's an example:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: {
    home: "./src/home-module.js",
    promo: "./src/promo-module.js",
    music: "./src/music-module.js"
  },
  output: {
    filename: "[contenthash].bundle.js",
    path: path.resolve(__dirname, "dist")
  }
}

The output.filename option tells Webpack to create each bundle's filename by concatenating each chunk's content hash with the ".bundle.js" string value.

Keep in mind that Webpack allows you to combine different substitutions—for instance, filename: "[name].[contenthash].bundle.js".

You can also use a function to return a filename like so:

filename: (pathData) => {
  return pathData.chunk.name === "main" ? "[name].js" : "[name].bundle.js";
}

Webpack also permits you to initialize the filename property with a folder structure like so:

filename: "codesweetly/[name]/bundle.js"

Now, let's discuss the third property developers commonly use within the output field.

output.clean

As Webpack increasingly generates and saves files into your output directory, it is common to clutter a project's /dist folder with unused files.

So, a good practice is to clean your output directory before each build step. By so doing, your /dist folder will contain used files only.

Let's see how to do the cleanup below:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "codesweetly.js",
    path: path.resolve(__dirname, "dist"),
    clean: true
  }
}

The clean option in the snippet above tells Webpack to clean the project's output directory before each build step.

In other words, Webpack will empty the output directory before it begins each build step.

Therefore, the output directory will contain only the files generated from the compilation process—not any of the old files that Webpack previously saved there.

Let's now discuss another popular configuration option that you can use to alter (or extend) Webpack's default settings.

module

The module field makes Webpack process assets—like CSS files and fonts—as modules in the dependency graph.

So, suppose you want Webpack to bundle non-JavaScript assets such as images, CSS files, fonts, and so on. In such a case, you can use the module option to specify how Webpack should manage those assets before adding them to the dependency graph.

Below are some common ways to use the module option.

How to use Webpack's module option to load CSS stylesheets

Here's how you can use Webpack's module option to load CSS stylesheets:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist")
  },
  module: {
    rule: [
      {
        test: /\.css$/i,
        use: ["style-loader", "css-loader"]
      }
    ]
  }
}

The configuration snippet above used the module property to tell Webpack to use "style-loader" and "css-loader" to load CSS files.

Keep in mind that the loaders' order matters.

In other words, Webpack reads the loaders from right to left. Therefore, it will first execute the "css-loader" before the "style-loader".

So, "css-loader" will pass its result (that is, the processed resource) to the "style-loader". Then, "style-loader" will insert the final CSS resource into the <head> element of your HTML page.

It is necessary to install the loaders you want Webpack to use in loading your CSS assets.

So, for instance, before Webpack can use the previous configuration file to load ".css" assets, you need to install "style-loader" and the "css-loader".

Here's how to install the two loaders:

npm install style-loader css-loader --save-dev

Alternatively, if your package manager is Yarn, run:

yarn add style-loader css-loader --dev

Note:

  • "css-loader" helps to interpret and resolve @import and url() items such as import, require(), and url('./my-image.png').
  • "style-loader" helps to inject a <style> tag and the styles derived from "css-loader" to your project's HTML file.

Let's now see how to use the module option to load images.

How to use Webpack's module option to load images

Here's how you can use Webpack's module option to load images:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist")
  },
  module: {
    rule: [
      {
        test: /\.(png|svg|jpg|jpeg|gif)$/i,
        type: "asset/resource"
      }
    ]
  }
}

The configuration snippet above used the module property to tell webpack to load ".png", ".svg", ".jpg", ".jpeg", and ".gif" files as resource asset modules.

So, suppose the following import statement is in your script file:

import anyImage from "./your-image.png";

In such a case, here's how Webpack will load the image:

  1. Webpack will process your-image.png.
  2. It will add the processed image to your output directory.
  3. Webpack will initialize the anyImage variable with the processed image's URL.

Note: While processing and adding your-image.png to the output folder, Webpack will change the image's filename to something like 150b55a1bf7461efb720.png.

Let's now see how to use the module option to load fonts.

How to use Webpack's module option to load fonts

Here's how you can use Webpack's module option to load fonts:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist")
  },
  module: {
    rule: [
      {
        test: /\.(woff|woff2|eot|ttf|otf)$/i,
        type: "asset/resource"
      }
    ]
  }
}

The configuration snippet above used the module property to tell Webpack to load ".woff", ".woff2", ".eot", ".ttf", and ".otf" files as resource asset modules.

Once you've configured the loader, you can incorporate your fonts via the @font-face CSS declaration.

Here's an example:

/* styles.css */

@font-face {
  font-family: "Digital7";
  src: url("./digital-7.regular.woff") format("woff"),
       url("./digital-7.regular.ttf") format("truetype");
  font-weight: 600;
  font-style: italic;
}

div {
  color: red;
  font-family: "Digital7";
}

Whenever css-loader loads the stylesheet above, it will process the specified fonts and add the processed copies to your project's output directory.

Note:

  • Webpack will change the processed fonts' filename to something similar to 93911ab167c943140756.ttf.
  • See Webpack's documentation to learn how to load JSON, CSV, TSV, and XML files.

Let's now discuss another popular configuration option that you can use to alter (or extend) Webpack's default settings.

devtool

The devtool field tells Webpack to convert a compiled file to the source code format. Therefore, making it easier for you to debug the exact file (and line) where an error occurred in your source code.

Here's an example:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist")
  },
  devtool: "source-map"
}

At compilation time, if Webpack sees a devtool property in your configuration script, it will generate a .js.map file that the browser will use instead of the .js file.

Note: There are different devtool options for specifying if and how Webpack should generate the source maps.

Let's now discuss another popular configuration option that you can use to alter (or extend) Webpack's default settings.

mode

The mode field tells Webpack the specific built-in optimization configuration you want it to use to build your output file.

You can specify whether Webpack should use production, development, or no (none) configuration to optimize your bundle. Let's discuss each of the three optimization settings below.

Development mode

A mode: "development" setting tells Webpack to build an output file for use in the development environment.

Here's an example:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist")
  },
  devtool: "source-map",
  mode: "development"
}

Setting a mode: "development" configuration will make Webpack create a bundle that:

  • is fast to build
  • is less optimized
  • includes comments
  • is not minified
  • produces helpful error messages
  • is easy to debug

Here's an example of a mode: "development" bundle:

A development mode bundle Image of a development mode bundle compiled with webpack

To make a non-minified output file readable, ensure Webpack's devtool field is not eval.

Whenever you set the mode to development, Webpack may default devtool's value to eval. So, ensure to select a different devtool—like source-map or disable it by setting its value to "false"—whenever you wish to make your output file readable.

Suppose you choose to run Webpack in development mode. In that case, remember to change your configuration to production mode when you are ready to deploy your app.

Now, let's discuss configuring Webpack to build your output file in production mode.

Production mode

A mode: "production" setting tells Webpack to build an output file for use in the production environment.

Here's an example:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist")
  },
  devtool: "source-map",
  mode: "production"
}

Setting a mode: "production" configuration will make Webpack create a bundle that:

  • is slow to build
  • is more optimized
  • excludes comments
  • is minified
  • does not produce detailed error messages
  • is difficult to debug

Here's an example of a mode: "production" bundle:

A production mode bundle Image of a production mode bundle compiled with webpack

Note: Webpack recommends having source maps—like source-map—enabled in production.

Now, let's discuss configuring Webpack to build your output file without any optimization settings.

None mode

A mode: "none" setting tells Webpack to build an output file without optimizing it for development or production.

Here's an example:

// webpack.config.js

const path = require("path");

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

Here's an example of a mode: "none" bundle:

A none mode bundle Image of a none mode bundle compiled with webpack

Important stuff to know about the mode option

To make switching between development and production mode easy, you can store the mode configurations in the "scripts" field of your package.json file.

Here's an example:

{
  "name": "your-app-name",
  "version": "1.0.0",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "webpack --mode development",
    "build": "webpack --mode production"
  }
}

The snippet above initialized the scripts' "dev" property with Webpack's development mode command.

Likewise, we initialized the scripts' "build" property with Webpack's production mode command.

Therefore, suppose you execute npm run dev on your terminal. In that case, Webpack will execute the build step in development mode.

Overview

This article discussed what a JavaScript module is and how it works. We also discussed how to use a popular module bundler (Webpack) to bundle a project's JavaScript file and its dependencies into a single output file.

And there we have it. I hope you have found this article helpful.

Thanks for reading!

And here's a useful ReactJS resource:

I wrote a book about React!

  • It's beginners friendly ✔
  • It has live code snippets ✔
  • It contains scalable projects ✔
  • It has plenty of easy-to-grasp examples ✔

The React Explained Clearly book is all you need to understand ReactJS.

React Explained Clearly Book Now Available at Amazon

]]> <![CDATA[ Popular Front End Development Tools You Should Know ]]> https://www.freecodecamp.org/news/front-end-development-tools-you-should-know/ 66d45e4273634435aafcef82 Tue, 03 Nov 2020 02:35:19 +0000 By Yiğit Kemal Erinç

If you are just getting started with JavaScript, the number of tools and technologies you'll hear about may be overwhelming. And you might have a hard time deciding which tools you actually need.

Or maybe you're familiar with the tools, but you haven't given much thought to what problems they solve and how miserable your life would be without their help.

I believe it is important for Software Engineers and Developers to understand the purpose of the tools we use every day.

That's why, in this article, I look at NPM, Babel, Webpack, ESLint, and CircleCI and I try to clarify the problems they solve and how they solve them.

NPM

Image

NPM is the default package manager for JavaScript development. It helps you find and install packages (programs) that you can use in your programs.

You can add npm to a project simply by using the "npm init" command. When you run this command it creates a "package.json" file in the current directory. This is the file where your dependencies are listed, and npm views it as the ID card of the project.

You can add a dependency with the "npm install (package_name)" command.

When you run this command, npm goes to the remote registry and checks if there is a package identified by this package name. If it finds it, a new dependency entry is added to your package.json and the package, with it's internal dependencies, is downloaded from the registry.

You can find downloaded packages or dependencies under the "node_modules" folder. Just keep in mind that it usually gets pretty big – so make sure to add it to .gitignore.

How to keep your JavaScript libraries up to date - LogRocket Blog

NPM does not only ease the process of finding and downloading packages but also makes it easier to work collaboratively on a project.

Without NPM, it would be hard to manage external dependencies. You would need to download the correct versions of every dependency by hand when you join an existing project. And that would be a real hassle.

With the help of npm, you can just run "npm install" and it will install all external dependencies for you. Then you can just run it again anytime someone on your team adds a new one.

Babel

Image

Babel is a JavaScript compiler or transpiler which translates the ECMAScript 2015+ code into code that can be understood by older JavaScript engines.

Babel is the most popular Javascript compiler, and frameworks like Vue and React use it by default. That said, concepts we will talk about here are not only related to Babel and will apply to any JavaScript compiler.

Why do you need a compiler?

"Why do we need a compiler, isn't JavaScript an interpreted language?" you may ask if you are familiar with the concepts of compiled and interpreted languages.

It's true that we usually call something a "compiler" if it translates our human-readable code to an executable binary that can be understood by the CPU. But that is not the case here.

The term transpiler may be more appropriate since it is a subset of a compiler: Transpilers are compilers that translate the code from a programming language to another language (in this example, from modern JS to an older version).

JavaScript is the language of browsers. But there is a problem with browsers: Cross compatibility. JavaScript tools and the language itself are evolving rapidly and many browsers fail to match that pace. This results in compatibility issues.

You probably want to write code in the most recent versions of JavaScript so you can use its new features. But if the browser that your code is running has not implemented some of the new features in its JavaScript engine, the code will not execute properly on that browser.

This is a complex problem because every browser implements the features at a different speed. And even if they do implement those new features, there will always be people who use an older version of their browser.

So what if you want to be able to use the recent features but also want your users to view those pages without any problems?

Before Babel, we used polyfills to run older versions of certain code if the browser did not support the modern features. And when you use Babel, it uses polyfills behind the scenes and does not require you to do anything.

How do transpilers/compilers work?

Babel works similar to other compilers. It has parsing, transformation, and code generation stages.

We won't go in-depth here into how it works, since compilers are complicated things. But to understand the basics of how compilers work, you can check out the the-super-tiny-compiler project. It is also mentioned in Babel's official documentation as being helpful in understanding how Babel works.

We can usually get away with knowing about Babel plugins and presets. Plugins are the snippets that Babel uses behind the scenes to compile your code to older versions of JavaScript. You can think of each modern feature as a plugin. You can go to this link to check out the full list of plugins.

Image List of plugins for ES5

Presets are collections of plugins. If you want to use Babel for a React project you can use the pre-made @babel/preset-react which contains the necessary plugins.

Image React Preset Plugins

You can add plugins by editing the Babel config file.

Do you need Babel for your React App?

For React, you need a compiler because React code generally uses JSX and JSX needs to be compiled. Also the library is built on the concept of using ES6 syntax.

Luckily, when you create a project with create-react-app, it comes with Babel already configured and you usually do not need to modify the config.

Examples of a compiler in action

Babel's website has an online compiler and it is really helpful to understand how it works. Just plug in some code and analyze the output.

Image

Image

Webpack

Image

Webpack is a static module bundler. When you create a new project, most JavaScript frameworks/libraries use it out of the box nowadays.

If the phrase "static module bundler" sounds confusing, keep reading because I have some great examples to help you understand.

Why do you need a bundler?

In web apps you're going to have a lot of files. This is especially the case for Single Page Applications (React, Vue, Angular), with each having their own dependencies.

What I mean by a dependency is an import statement – if file A needs to import file B to run properly, then we say A depends on B.

In small projects, you can handle the module dependencies with <script> tags. But when the project gets larger, the dependencies rapidly become hard to manage.

Maybe, more importantly, dividing the code into multiple files makes your website load more slowly. This is because the browser needs to send more requests compared to one large file, and your website starts to consume a ton of bandwidth, because of HTTP headers.

We, as developers want our code to be modular. We divide it into multiple files because we do not want to work with one file with thousands of lines. Still, we also want our websites to be performant, to use less bandwidth, and to load fast.

So now, we'll see how Webpack solves this issue.

How Webpack works

When we were talking about Babel, we mentioned that JavaScript code needs to be transpiled before the deployment.

But compiling with Babel is not the only operation you need before deploying your project.

You usually need to uglify it, transpile it, compile the SASS or SCSS to CSS if you are using any preprocessors, compile the TypeScript if you are using it...and as you can see, this list can get long easily.

You do not want to deal with all those commands and operations before every deployment. It would be great if there was a tool that did all that for you in the correct order and correct way.

The good news – there is: Webpack.

Webpack also provides features like a local server with hot reload (they call it hot module replacement) to make your development experience better.

So what's hot reloading? It means that whenever you save your code, it gets compiled and deployed to the local HTTP server running on your machine. And whenever a file changes, it sends a message to your browser so you do not even need to refresh the page.

If you have ever used "npm run serve", "npm start" or "npm run dev", those commands also start Webpack's dev server behind the scenes.

Webpack starts from the entry point of your project (index) and generates the Abstract Syntax Tree of the file. You can think of it as parsing the code. This operation is also done in compilers, which then look for import statements recursively to generate a graph of dependencies.

It then converts the files into [IIFEs](https://developer.mozilla.org/en-US/docs/Glossary/IIFE#:~:text=An%20IIFE%20(Immediately%20Invoked%20Function,soon%20as%20it%20is%20defined.) to modularize them (remember, putting code inside a function restricts its scope). By doing this, they modularize the files and make sure the variables and functions are not accessible to other files.

Without this operation, it would be like copying and pasting the code of the imported file and that file would have the same scope.

Webpack does many other advanced things behind the scenes, but this is enough to understand the basics.

Bonus – ESLint

Image

Code quality is important and helps keep your projects maintainable and easily extendable. While most of us developers recognize the significance of clean coding, we sometimes tend to ignore the long term consequences under the pressure of deadlines.

Many companies decide on coding standards and encourage developers to obey those standards. But how can you make sure that your code meets the standards?

Well, you can use a tool like ESLint to enforce rules in the code. For example, you can create a rule to enforce or disallow the usage of semicolons in your JavaScript code. If you break a rule, ESLint shows an error and the code does not even get compiled – so it is not possible to ignore that unless you disable the rule.

Linters can be used to enforce standards by writing custom rules. But you can also use the pre-made ESLint configs established by big tech companies to help devs get into the habit of writing clean code.

You can take a look at Google's ESLint config here – it is the one I prefer.

ESLint helps you get used to best practices, but that's not its only benefit. ESLint also warns you about possible bugs/errors in your code so you can avoid common mistakes.

Image

Bonus – CI/CD (CircleCI)

Image

Continuous Integration/Development has gained a lot of popularity in recent years as many companies have adopted Agile principles.

Tools like Jenkins and CircleCI allow you to automate the deployment and testing of your software so you can deploy more often and reliably without going through difficult and error-prone build processes by yourselves.

I mention CircleCI as the product here because it is free and used frequently in JavaScript projects. It's also quite easy to use.

Let's go over an example: Say you have a deployment/QA server and your Git repository. You want to deploy your changes to your deployment/QA server, so here is an example process:

  1. Push the changes to Git
  2. Connect to the server
  3. Create a Docker container and run it
  4. Pull the changes to the server, download all the dependencies (npm install)
  5. Run the tests to make sure nothing is broken
  6. Use a tool like ESLint/Sonar to ensure code quality
  7. Merge the code if everything is fine

With the help of CircleCI, you can automatically do all these operations. You can set it up and configure to do all of the above operations whenever you push a change to Git. It will reject the push if anything goes wrong, for example a failing test.

I will not get into the details of how to configure CircleCI because this article is more about the "Why?" of each tool. But if you are interested in learning more and seeing it in action, you can check out this tutorial series.

Conclusion

The world of JavaScript is evolving rapidly and new tools are gaining popularity every year.

It's easy to react to this change by just learning how to use the tool – we are often too busy to take our time and think about the reason why that tool became popular or what problem it solves.

In this article, I picked the tools I think are most popular and shared my thoughts on their significance. I also wanted to make you think about the problems they solve rather than just the details of how to use them.

If you liked the article you can check out and subscribe to my blog where I try to write frequently. Also, let me know what you think by commenting so we can brainstorm or you can tell me what other tools you love to use :)

]]> <![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[ How to share variables across HTML, CSS, and JavaScript using Webpack ]]> https://www.freecodecamp.org/news/how-to-share-variables-across-html-css-and-javascript-using-webpack/ 66d45d5fb3016bf139028d0d Fri, 20 Dec 2019 00:30:00 +0000 By Adrien Zaganelli

Earlier this week, I read an article explaining how CSS-in-JS slows down the rendering of some React apps and how static CSS is faster. But CSS-in-JS is very popular because, among other features, you can style dynamically using JavaScript variables.

In this tutorial, I will show you how to recreate this perk in any of your web projects thanks to Webpack (and I assume you know how to use it). To start, we want Webpack to bundle our source files into a static dist/ folder .

You can check out the source code here.

1. Set up our app

The boring part

Create a folder for this tutorial, open your terminal, and init a project:

npm init -y

First things first, if it’s not already done, install node.js and Webpack:

npm install webpack webpack-cli --save-dev

Let’s create a script in our package.json that tells Webpack to use our config file:

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

At the root of your folder, create a globals.js file, where our shared variables will be stored:

module.exports = {
  myTitle: 'Hello freeCodeCamp!',
  myColor: '#42ff87',
};

The Webpack config file looks like this (webpack.config.js). Create it at the root of your folder:

module.exports = {
  entry: __dirname + '/app/index.js',
  output: {
    path: __dirname + '/dist',
    filename: 'index_bundle.js'
  },
};

Our source code will be located in an app folder. Create it like this:

mkdir app && cd app

You’ll need index.html and index.js files at this point. Create those files in the app folder:

touch index.html index.js

Perfect! You’re all set. ?

Your folder should look like this:

|-- node_modules/
|-- package.json
|-- webpack.config.js
|-- globals.js
|-- app/
    |-- index.html
    |-- index.js

2. Render our HTML files with the html-webpack-plugin

This app/index.html is empty. Let’s add some markup in it and then add a custom variable:

<html lang="en">
<head>
  <title>Webpack shared variables!</title>
</head>
<body>
  <h1><%= myTitle %></h1>
</body>
</html>

As you can see, we are trying to print a variable in our HTML... which is impossible! To make it work we’ll use the html-webpack-plugin that gives us the ability to use EJS syntax and inject data into it.

The plugin will generate a valid HTML file. In the meantime, you should rename your app/index.html file to app/index.ejs.

npm install --save-dev html-webpack-plugin

Let’s go back to our configuration file. html-webpack-plugin has an interesting templateParameters option that allows us to pass an object as parameter. Enable the plugin as follows in webpack.config.js:

const HtmlWebpackPlugin = require('html-webpack-plugin');
const globals = require('./globals.js')

module.exports = {
    // ... previous config, entry, output...
  plugins: [
    new HtmlWebpackPlugin({
      template: 'app/index.ejs',
      templateParameters: globals,
    })
  ]
};

Run npm run build and ta-daaaaa « <%= myTitle %> » became « Hello freeCodeCamp » ! The work is done by Webpack during the compilation when it runs the html-webpack-plugin.

See? This was pretty simple with the right tool: HTML ✅

3. Use our variables in JavaScript

Phew, so many lines just to print a variable! ?With Webpack, things often get complicated. Well, this one is very simple: in JavaScript just import your file. In your app/index.js:

import globals from '../globals.js'

document.write(
'<pre>' +
  JSON.stringify(globals, null, 2) +
'</pre>'
);

This will print our globals object on the page. Now let’s move on to the CSS.

4. Use shared variables in our CSS

Here is our final boss ?

Okay guys you got me… I lied. We can’t use our globals directly in CSS – we must use a pre-processor. In this example, we will use SASS.

On the Webpack side, a plugin will not be enough. We must use a loader to convert SASS into CSS. In this case we need the sass-loader package, so install it according to the docs:

npm install sass-loader node-sass css-loader style-loader --save-dev

Back to coding. Now that we have SASS, create your style sheet file, app/style.scss:

h1 {
  color: $myColor;
}

Our SASS is set up – now how can we inject data into it? The sass-loader package has a prependData option! But it takes a string as a parameter, which means that your data should look like this: "$myColor: red; myTitle: '...'";.

We have to automate that and convert a JavaScript object into a string. I didn’t find a package on npm that satisfied me, so I wrote my own converter. Download the file and add it to your project (in my example it's utils/jsToScss.js).

Your final webpack.config.js should look like this:

const globals = require("./globals.js");
const HtmlWebpackPlugin = require("html-webpack-plugin");
const jsToScss = require("./utils/jsToScss.js");

module.exports = {
  entry: __dirname + "/app/index.js",
  output: {
    path: __dirname + "/dist",
    filename: "index_bundle.js"
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "app/index.ejs",
      templateParameters: globals
    })
  ],
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          // Creates `style` nodes from JS strings
          "style-loader",
          // Translates CSS into CommonJS
          "css-loader",
          // Compiles Sass to CSS
          {
            loader: "sass-loader",
            options: {
              prependData: jsToScss(globals)
            }
          }
        ]
      }
    ]
  }
};

Here is what you should see:

Image https://glitch.com/edit/#!/shared-variables-webpack?path=webpack.config.js

If you are still reading this tutorial, thanks for your attention. I hope it helps you! Webpack is a very powerful tool you should dig more into ?

NB: In your dist/ folder you can see there isn't any CSS generated. That's because I use the style-loader to keep this demo simple. To generate the CSS file, take a look at the mini-css-extract-plugin.

]]> <![CDATA[ Learn webpack to simplify and speed up your website ]]> https://www.freecodecamp.org/news/webpack-course/ 66b2070deea9870582e16cea Wed, 19 Jun 2019 15:10:01 +0000 Wepback is a JavaScript module bundler and is useful in many development workflows. Learn Webpack from Colt Steele in this full course.

The course begins with a simple question: "What is webpack?" Then you will learn about installing Webpack, configuring it, and adding loaders for CSS, SASS, HTML, and Files.

The course covers cache busting, setting up a dev server, and splitting up your development and production config files. You will learn about multiple Webpack plugins including clean-webpack-plugin, mini-css-extract-plugin, optimize-css-assets-webpack-plugin, terser-webpack-plugin, and html-webpack-plugin.

You can watch the full video course on the freeCodeCamp.org YouTube channel (2 hour watch).

]]> <![CDATA[ How to improve performance in your apps with Lighthouse, Webpack, and React Loadable Components ]]> https://www.freecodecamp.org/news/taming-performance-in-todays-web-app-with-lighthouse-webpack-and-react-loadable-components-b2d3fa04e0ab/ 66c3603fc337fbd10a4b5973 Wed, 27 Feb 2019 13:57:16 +0000 By Adam Henson

An overview of modern concepts, tools and example strategies to improve web page performance

Image Not Impressed at Penn Station

In March of 2018 Google confirmed rumors by announcing the migration of sites for “mobile-first” indexing.

What this Means

Mobile-first indexing means Google will predominantly use the mobile version of the content for indexing and ranking. Historically, the index primarily used the desktop version of a page’s content when evaluating the relevance of a page to a user’s query. Since the majority of users now access Google via a mobile device, the index will primarily use the mobile version of a page’s content going forward. We aren’t creating a separate mobile-first index. We continue to use only one index.~[Prepare for mobile-first indexing](http://Mobile-first indexing means Google will predominantly use the mobile version of the content for indexing and ranking. Historically, the index primarily used the desktop version of a page's content when evaluating the relevance of a page to a user's query. Since the majority of users now access Google via a mobile device, the index will primarily use the mobile version of a page's content going forward. We aren't creating a separate mobile-first index. We continue to use only one index.)

“Yikes!” — you may be thinking. This is a reasonable reaction for anyone owning a website relying on organic search results for its success. Consider extreme examples of websites that drive millions of dollars a day who’ve come to depend on such rankings. Many of these websites weren’t necessarily built to support mobile devices as the highest priority.

Confronting Performance

The first step in ensuring optimal performance of a web page on a mobile device is to understand key metrics in modern testing. We can go straight to the source by utilizing Lighthouse, Google’s open-source tool. You can run it in Chrome DevTools, from the command line, or as a Node module.

Lighthouse has a variety of options to allow performance testing under a variety of conditions, specifically notable being device and connection type.

Lighthouse Metrics and Scoring

In a Lighthouse performance audit, results are provided as a set of metrics with values. The score is a number between 0 and 100 where the higher number is better. Score is calculated by a weighted group of select metrics as explained in the documentation.

Load is not a single moment in time — it’s an experience that no one metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as “fast” or “slow”.

~ Paint Timing Spec

Not only does each metric capture a characteristic of page load, but each metric can encompass the results of others.

Image Nobody is perfect — an audit of the Lighthouse’s own documentation page

Opportunities for Improvement and Solutions

I’ve identified a few commonly low metrics with fairly straightforward solutions, depending on complexity. “Time to Interactive” is one of the most important.

Time to Interactive

At the time of this writing, the “Time to Interactive” metric is weighted highest in its influence on the overall performance score.

The Time to Interactive (TTI) metric measures how long it takes a page to become interactive. “Interactive” is defined as the point where:

The page has displayed useful content, which is measured with First Contentful Paint.

Event handlers are registered for most visible page elements.

The page responds to user interactions within 50 milliseconds.

To improve your TTI score, defer or remove unnecessary JavaScript work that occurs during page load. See Optimize JavaScript Bootup and Reduce JavaScript Payloads with Tree Shaking, and Reduce JavaScript Payloads with Code Splitting.

~Time to Interactive

Improving Time to Interactive

Webpack provides sophisticated customization nowadays to improve optimization. It provides out of the box configuration options to split code and prevent duplication as illustrated in the documentation. By using Webpack Bundle Analyzer, we can visualize the outcome of a “prevent duplication” code splitting approach.

Image Webpack Bundle Analyzer: Standard code splitting of a “vendors” bundle

Okay, well… could be worse ?! The important part is we separated common code. By doing this alone we relieve work from the main execution thread, provide asset caching potential, and other interesting things as detailed by Addy Osmani and Jeremy Wagner. But wait… there’s more!

Dynamic Code Splitting

We talked about one approach above. Another code splitting technique supported by Webpack involves the use of dynamic imports. I accomplished this fairly easily with staggering results by using Loadable Components to handle rendering in my “universal” app. I chose this library in its support of “Server Side Rendering” and documentation of it. It provides a Babel Plugin (which delegates chunks under the hood during build) and a Chunk Extractor — to collect chunks server side and provide script tags on page render. This seems confusing, so enough with the words… let’s role up our sleeves!

Imagine a page component, defined with a dynamic import.

And to process and delegate Loadable Components during build, we can configure Webpack with the Babel plugin (mentioned above).

In our client side render entry, we wrap in Loadable Ready. Loadable Components loads all your scripts asynchronously to ensure optimal performance. All scripts are loaded in parallel, so you have to wait for them to be ready using loadableReady .

On server side render, Loadable Components ChunkExtractor provides only the script tags used by initial page load and the rest asynchronously, client side! JS is loaded on-demand, behind the scenes.

Dynamically extracting script and style tags needed by a particular page is quite powerful. I used dynamic imports in all page components and components that uniquely import heavy libraries. What a difference! ?

Image Webpack Bundle Analyzer: Dynamic code splitting

We reduced the main vendor bundle by more than 100kb. The blue squares in the image above represent bundles created with dynamically imported page components. The large violet square in the top middle is a vendor split bundle from one specific component I identified as uniquely importing large libraries.

Okay, Did We Actually Do Anything?

The short answer is — yes!! We can see how JS is loaded by examining the network panel in Chrome Dev Tools. Let’s assume a request to a home page.

Image Chrome Dev Tools network panel: An example home page

Okay, wait… it’s all coming back now…

An alternative to large bundles is code-splitting, which is where JavaScript is split into smaller chunks. This enables sending the minimal code required to provide value upfront, improving page-load times. The rest can be loaded on demand.

~ Reduce JavaScript Payloads with Code Splitting

Aha, we can see this in action here as a user navigates to another route client side. Assume the user navigates to a “dashboard” page from the home page. Dashboard.fc4871b3.js is downloaded on demand!

Image Chrome Dev Tools network panel: An example home page and client side navigation to a “dashboard” page

And… Google loves it! With the above changes, I saw a Lighthouse score improvement of more than 10 points. ?

Image A Lighthouse audit with success written all over it!

Conclusion

By utilizing a recipe of modern tools and features, we can effectively identify, measure, visualize and address web page performance. This is important in accommodating Google’s mobile-first indexing. Key metrics documented by Google to measure performance, such as “Time to Interactive”, can help us pinpoint opportunities for improvement.

]]> <![CDATA[ How to configure Webpack 4 with Angular 7: a complete guide ]]> https://www.freecodecamp.org/news/how-to-configure-webpack-4-with-angular-7-a-complete-guide-9a23c879f471/ 66c350b130aba6677fb9fa22 Tue, 15 Jan 2019 21:52:12 +0000 By Samuel Teboul

The Angular CLI makes it easy to create an application that already works, right out of the box. It is a great tool, but have you never thought: "How does it work? How can I build an application without the CLI?"

Those questions came to my mind when Angular 7 was released. I started to look for answers on the web and what I found was not up-to-date for my purpose. Indeed, as Angular and webpack are always evolving, so dependencies and configurations.

In this article you are about to learn:

  • How to setup an Angular 7 basic application, from scratch
  • How to configure webpack for development mode (Just-in-Time compilation)
  • How to configure webpack for production mode (Ahead-of-Time compilation)

Angular 7: setup a basic app

Create a new package.json file and add the following lines to install Angular and its dependencies.

"dependencies": 
  "@angular/animations": "~7.0",
  "@angular/common": "~7.0",
  "@angular/compiler": "~7.0",
  "@angular/compiler-cli": "~7.0",
  "@angular/core": "~7.0",
  "@angular/forms": "~7.0",
  "@angular/http": "~7.0",
  "@angular/platform-browser": "~7.0",
  "@angular/platform-browser-dynamic": "~7.0",
  "@angular/platform-server": "~7.0",
  "@angular/router": "~7.0",
  "@angular/upgrade": "~7.0",
  "core-js": "~2.5",
  "rxjs": "~6.3",
  "zone.js": "~0.8"
}

I have struggled for a long time to find the best folder structure that fits every Angular project, especially when the application grows in size. This article has taught me a lot on the subject.

Create a new src folder and the following folders/files inside it. All our Angular app business logic will be in this folder.

src
|__ app
    |__ modules
        |__ menu
            |__ components
                |__ menu
                    |__ menu.component.html
                    |__ menu.component.scss
                    |__ menu.component.ts
            |__ menu.module.ts
            |__ menu-routing.module.ts
|__ shared
         |__ components
             |__ home
                 |__ home.component.html
                 |__ home.component.scss
                 |__ home.component.ts
|__ app.component.html
        |__ app.component.scss        
        |__ app.component.ts
        |__ app.module.ts
        |__ app-routing.module.ts
|__ index.html
|__ main.ts

Every application has at least one Angular module, the root module that you bootstrap to launch the application. By convention, it is usually called AppModule. I create another module, the MenuModule to show you how you can use lazy loading in your project, especially for production.

Some important points :

  • index.html

Add <base href=”/”> tells our Angular router how to compose navigation URLs . This line means that your app will start from root folder i.e locally it would consider localhost:3000/ and on server it would consider root folder.

  • app-routing.module.ts

There are three main steps to setting up a lazy loaded feature module:

  1. Create the feature module
  2. Create the feature module’s routing module
  3. Configure the routes

{path: ‘menu’, loadChildren:’./modules/menu/menu.module#MenuModule’} tells Angular to lazy load our feature module MenuModule by the time the user visit the /menu route.

TypeScript configuration

Add the following lines to your package.json file:

"devDependencies": {
  "@types/core-js": "~2.5",
  "@types/node": "~10.12",
  "typescript": "~3.1"
}

Create in your root project folder a tsconfig.json file:

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "sourceMap": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "noImplicitAny": true,
    "suppressImplicitAnyIndexErrors": true,
    "lib": ["es6", "dom"],
    "typeRoots": ["node_modules/@types"]
  },
  "exclude": ["node_modules"]
}

This is a basic TypeScript configuration file. It’s essential to install node and core-js types definition. Without it, TypeScript won’t be able to compile our Angular application to JavaScript.

Webpack configuration for development mode (Just-in-Time compilation)

First of all, what does compilation means ? It doesn’t mean compiling TypeScript files to JavaScript, this is not related to Angular. Angular itself needs to compile your HTML templates into JavaScript and this can occurred at 2 different points of time:

  • After your app is downloaded in the Browser (JiT)

Image JiT compilation

  • Right after development, at build time, before your app is downloaded in the Browser (AoT)

Image

What is webpack?

According to Wikipedia:

Webpack is an open source JavaScript module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset. Webpack takes modules with dependencies and generates static assets representing those modules. It’s a module bundler primarily for JavaScript, but it can transform front-end assets like HTML, CSS, even images if the corresponding plugins are included.

To tell webpack how to bundle our application we have to configure what we call the Core Concepts:

Entry — An entry point indicates which module webpack should use to begin building out its internal dependency graph. Webpack will figure out which other modules and libraries that entry point depends on (directly and indirectly).

Output — The output property tells webpack where to emit the bundles it creates and how to name these files. It defaults to ./dist/main.js for the main output file and to the ./dist folder for any other generated file.

Loaders — At a high level, loaders have two properties in your webpack configuration:

  • The test property identifies which file or files should be transformed.
  • The use property indicates which loader should be used to do the transforming.

Plugins — While loaders are used to transform certain types of modules, plugins can be leveraged to perform a wider range of tasks like bundle optimization, asset management, and injection of environment variables.

All of these must be set up in the webpack configuration file webpack.config.js.

Configuring webpack

In the src folder we need to create 2 more files:

  • vendor.ts that only imports the application's third-party modules.
  • polyfills.ts we need polyfills to run an Angular application in most browsers as explained in the Browser Support guide. This bundle file will load first so this is a good place to configure the browser environment for production or development.

Create a new config folder and the following files inside:

  • webpack.config.common.js : configuration that we will use for development and production.

Entry — For this application (and for most of them actually) we have 3 different entry points : vendor.ts polyfills.ts and main.ts.

entry: {
    vendor: './src/vendor.ts',
    polyfills: './src/polyfills.ts',
    main: './src/main.ts'
}

Loaders — We load .html files with html-loader which is pretty standard. Loading .scss files is a bit tricky for an Angular app and I struggled for many hours to figure out how to do it.

First of all, we must load sass files by using two loaders sass-loader and css-loader. If you want to make debugging easy, especially in development mode, it’s really important to add sourceMap: **true** as options. In an Angular application we add styles to component by passing a file path to styleUrls array as follow styleUrls: ["./path/styles.scss"] but we need to have style as a string and to-string-loader will do it for us and cast the output to a string.

{
    test: /\.html$/,
    loader: 'html-loader'
},
{
    test: /\.(scss|sass)$/,
    use: [
        'to-string-loader',
        { 
            loader: 'css-loader', 
            options: { 
                sourceMap: true 
            } 
        },
        { 
            loader: 'sass-loader', 
            options: { 
                sourceMap: true 
            } 
        }
    ],
    include: helpers.root('src', 'app')
}

Plugins — CleanWebpackPlugin will remove/clean your build folder(s) before building again. HtmlWebpackPlugin plugin will generate an HTML5 file for you that includes all your webpack bundles in the body using script tags. It only requires path to the template.

new CleanWebpackPlugin(
    helpers.root('dist'),
    {
        root: helpers.root(),
        verbose: true
    }
),
new HtmlWebpackPlugin({
    template: 'src/index.html'
})
  • webpack.config.dev.js is our webpack configuration that we will use for development mode only.
mode: "development"

In webpack 4, chosen mode tells webpack to use its built-in optimizations accordingly.

devtool: 'cheap-module-eval-source-map'

This option controls if and how source maps are generated. By using cheap-module-eval-source-map Source Maps from loaders are processed for better results. However, loader Source Maps are simplified to a single mapping per line.

output: {
    path: helpers.root('dist'),
    publicPath: '/',
    filename: '[name].bundle.js',
    chunkFilename: '[id].chunk.js'
}

The output key contains a set of options instructing webpack on how and where it should output your bundles, assets and anything else you bundle or load with webpack. Here we tell webpack to output our bundles to the dist folder.

optimization: {
    noEmitOnErrors: true
}

Skips the emitting phase whenever there are errors while compiling. This ensures that no erroring assets are emitted. The optimization key has many others options that are set by default depending on your webpack configuration mode (development/production). You can read more about it here.

{
    test: /\.ts$/,
    loaders: [
        'babel-loader',
        {
            loader: 'awesome-typescript-loader',
            options: {
                configFileName: helpers.root('tsconfig.json')
            }
        },
        'angular2-template-loader',
        'angular-router-loader'
    ],
    exclude: [/node_modules/]
}

angular-router-loader is a webpack loader that enables string-based module loading with the Angular Router.

angular2-template-loader is a chain-to loader that inlines all html and styles in Angular components.

awesome-typescript-loader is currently the faster webpack TypeScript loader. It uses dependency resolution to build modules dependency graph. This relatively speeds up the build process.

babel-loader allows transpiling JavaScript files.

devServer: {
    historyApiFallback: true,
    stats: 'minimal'
}

When using the HTML5 History API, the index.html page will likely have to be served in place of any 404 responses. For that we need to enable historyApiFallback.

stats option lets you precisely control what bundle information gets displayed. This can be a nice middle ground if you want some bundle information, but not all of it.

Adding scripts

Add the following lines to your package.json file:

"scripts": {
  "build:dev": "webpack-dev-server --inline --hot --progress --port 8080"
}

--hot enables webpack Hot Module Replacement (HMR). It exchanges, adds, or removes modules while an application is running, without a full reload. This can significantly speed up development in a few ways:

  • Retain application state which is lost during a full reload.
  • Save valuable development time by only updating what’s changed.
  • Modifications made to CSS/JS in the source code results in an instant browser update which is almost comparable to changing styles directly in the browser’s dev tools.

Now you are all setup! You can run npm run build:dev open your browser and navigate to localhost:8080.

Webpack configuration for production mode (Ahead-of-Time compilation)

Advantages of AoT compilation

  • With AoT, the browser downloads a pre-compiled version of the application. The browser loads executable code so it can render the application immediately, without waiting to compile the app first.
  • The compiler inlines external HTML templates and CSS style sheets within the application JavaScript, eliminating separate AJAX requests for those source files.
  • There’s no need to download the Angular compiler if the app is already compiled. The compiler is roughly half of Angular itself, so omitting it dramatically reduces the application payload.
  • The AoT compiler detects and reports template binding errors during the build step before users can see them.
  • AoT compiles HTML templates and components into JavaScript files long before they are served to the client. With no templates to read and no risky client-side HTML or JavaScript evaluation, there are fewer opportunities for injection attacks.

Configuring webpack

In your config folder create a new file webpack.config.prod.js

mode: 'production'

We usually proceed to AoT compilation in production mode and, as I wrote previously, in webpack 4, chosen mode tells webpack to use its built-in optimizations accordingly.

output: {
    path: helpers.root('dist'),
    publicPath: '/',
    filename: '[hash].js',
    chunkFilename: '[id].[hash].chunk.js'
}

We also tell webpack to output our bundles to the dist folder. We include a hash to the file names to leverage client level cache efficiently. This way webpack knows whether or not a file has changed. Webpack provides placeholders for this purpose. These strings are used to attach specific information to outputs. The most valuable ones are:

  • [id] returns the chunk id.
  • [path] returns the file path.
  • [name] returns the file name.
  • [ext] returns the extension. [ext] works for most available fields.
  • [hash] returns the build hash. If any portion of the build changes, this changes as well.
  • [chunkhash] returns an entry chunk-specific hash. Each entry defined in the configuration receives a hash of its own. If any portion of the entry changes, the hash will change as well. [chunkhash] is more granular than [hash] by definition.
  • [contenthash] returns a hash generated based on content.

It’s preferable to use particularly hash and chunkhash only for production as hashing is not essential during development.

optimization: {
    noEmitOnErrors: true,
    splitChunks: {
        chunks: 'all'
    },
    runtimeChunk: 'single',
    minimizer: [
        new UglifyJsPlugin({
            cache: true,
            parallel: true
        }),

         new OptimizeCSSAssetsPlugin({
             cssProcessor: cssnano,
             cssProcessorOptions: {
                 discardComments: {
                     removeAll: true
                 }
             },
             canPrint: false
         })
    ]
}
  • As in development mode, we want to skip the emitting phase whenever there are errors while compiling. This ensures that no erroring assets are emitted.
  • chunks: ‘all’ indicates which chunks will be selected for optimization. Providing all can be particularly powerful, because it means that chunks can be shared even between async and non-async chunks.
  • Imported modules are initialized for each runtime chunk separately. As webpack suggests, while working on a project with multiple entry points you want to have only one runtime instance. For that you need to set it to ‘single’.
  • UglifyJsPlugin uses uglify-js to minify your JavaScript files. We set cache and parallel properties to true in order to enable file caching and to use multi-process parallel running to improve the build speed. There are more options available and I invite you to learn more about this plugin.
  • OptimizeCSSAssetsPlugin will search for CSS assets during the webpack build and will optimize and minimize it. The CSS processor used for optimization is cssnano. All comments will be removed from our minified CSS and no messages will be print to the console.
module: {
    rules: [
        {
            test: /(?:\.ngfactory\.js|\.ngstyle\.js|\.ts)$/,
            loader: '@ngtools/webpack'
        }
    ]
}

plugins: [
    new ngw.AngularCompilerPlugin({
        tsConfigPath: helpers.root('tsconfig.aot.json'),
        entryModule: helpers.root('src', 'app', 'modules', 'app', 'app.module#AppModule')
    })
]

@ngtools/webpack is the official plugin that AoT compiles your Angular components and modules. The loader works with webpack plugin to compile your TypeScript. It’s important to include both, and to not include any other TypeScript compiler loader.

Adding main.aot.ts file

In the src folder add main.aot.ts file:

import { enableProdMode } from '@angular/core';
import { platformBrowser } from '@angular/platform-browser';

import { AppModuleNgFactory } from './app/app.module.ngfactory';

enableProdMode();

platformBrowser().bootstrapModuleFactory(AppModuleNgFactory);

Your main entry is a bit different in production mode and AoT compilation:

  • Import enableProdMode to disable Angular’s development mode, which turns off assertions and other checks within the framework.
  • Import platformBrowser AND NOT platformBrowserDynamic because in AoT compilation your application is shipped to the browser already compiled whereas in JiT compilation it occurs at the browser level.
  • Instead of importing AppModule you need to import AppModuleFactory which is your compiled application generated by our Angular compiler.

Adding scripts

Add the following scripts to your package.json file :

"webpack-prod": "cross-env NODE_ENV=production webpack --mode production"

"build:prod": "npm run build:clean && ngc && npm run webpack-prod && npm run build:clean"

"build:clean": "del-cli 'src/**/*.js' 'src/**/*.js.map' 'src/**/*.ngsummary.json' 'src/**/*.metadata.json' 'src/**/**/*.ngfactory.ts' 'src/**/*.ngstyle.ts' 'src/**/*.shim.ts'"

"serve": "lite-server"
  • build:clean: the Angular compiler generates many files in order to compile your application. To stay clean in our project, we delete all these files before compilation and after generating bundles.
  • build:prod: run the Angular compiler with ngc command and then run webpack in production mode to generate your bundles.
  • serve: I use lite-server to serve our application and see what it looks like. Of course, you won’t need it in a real world project because your app will be serve by the cloud.

Now, you can run npm run build:prod to compile your Angular application and build your bundles. Then, run npm run serve to serve your app to the browser.

Image Hugh Jackman enjoying the article

I hope you enjoyed this article! If you have any questions/suggestions, let me know in the comments below.

The project files are on my GitHub:

samteb/Angular-7-Webpack-4
_Contribute to samteb/Angular-7-Webpack-4 development by creating an account on GitHub._github.co

]]> <![CDATA[ An intro to Webpack: what it is and how to use it ]]> https://www.freecodecamp.org/news/an-intro-to-webpack-what-it-is-and-how-to-use-it-8304ecdc3c60/ 66c3440bf9d371e3aae2681a Tue, 15 Jan 2019 17:37:32 +0000 By Ashish Nandan Singh

Introduction

Okay, so I assume you have heard of webpack — that’s why you are here, right? The real question is what do you know about it? You might know a few things about it, like how it works, or you might have absolutely no clue. Either way, I can assure you that after reading this article, you’ll likely feel comfortable enough with the whole webpack situation.

After all — necessity is the mother of invention…

A perfect way to say why webpack exists is the above quote. But to understand it better we need to go back, way back, to when JavaScript was not the new sexy thing, in those old timey ages when a website was just a small bundle of good old _._html, CSS, and probably one or a few JavaScript files in some cases. But very soon all of this was going to change.

What was the problem?

The entire dev community was involved in a constant quest of improving the overall user and developer experience around using and building javascript/web applications. Therefore, we saw a lot of new libraries and frameworks introduced.

A few design patterns also evolved over time to give developers a better, more powerful yet very simple way of writing complex JavaScript applications. Websites before were no more just a small package with an odd number of files in them. They stated getting bulky, with the introduction of JavaScript modules, as writing encapsulated small chunks of code was the new trend. Eventually all of this lead to a situation where we had 4x or 5x he of files in the overall application package.

Not only was the overall size of the application a challenge, but also there was a huge gap in the kind of code developers were writing and the kind of code browsers could understand. Developers had to use a lot of helper code called polyfills to make sure that the browsers were able to interpret the code in their packages.

To answer these issues, webpack was created. Webpack is a static module bundler.

So how was Webpack the answer?

In brief, Webpack goes through your package and creates what it calls a dependency graph which consists of various modules which your webapp would require to function as expected. Then, depending on this graph, it creates a new package which consists of the very bare minimum number of files required, often just a single bundle.js file which can be plugged in to the html file easily and used for the application.

Over the next part part of this article I will take you through the step by step setup of webpack. By the end of it, I hope you understand the basics of Webpack. So lets get this rolling…

What are we building ?

You have probably heard of ReactJS. If you know reactJS, you likely know what create-react-app is. For those of you who have no idea what either of those two things are, ReactJS is a UI library which is very helpful in building intelligent complex UIs, and create-react-app is a CLI tool for setting up or bootstrapping a boilerplate dev setup to make React applications.

Today we will be creating a simple React application but without using the create-react-app CLI. I hope this sounds fun enough to you. :)

Installation Phase

npm int

Thats right, thats how almost all good things start: plain old npm init. I will be using VS Code, but feel free to use any code editor you like to get things started.

Before you can do any of this, thought, make sure you have the latest nodeJS and the npm version installed locally on your machine. Click on each of those links to know more about the process.

$ npm init

This will create a starter package and add a package.json file for us. This is where all the dependencies required to build this application will be mentioned.

Now for creating a simple React application, we need two main libraries: React and ReactDOM. So let’s get them added as dependencies into our application using npm.

$ npm i react react-dom --save

Next up we need to add webpack, so we can bundle our app together. Not only bundle, but we will also require hot reloading which is possible using the webpack dev server.

$ npm i webpack webpack-dev-server webpack-cli --save--dev

The --save--dev is to specify that these modules are just dev dependencies. Now since we are working with React, we must keep in mind that React uses ES6 classes and import statements, something that all the browsers may not be able to understand. To make sure that the code is readable by all browsers, we need a tool like babel to transpile our code to normal readable code for browsers.

$ npm i babel-core babel-loader @babel/preset-react     @babel/preset-env html-webpack-plugin --save-dev

Well what can I say, that was the maximum number of installs I promise. In the case of babel, we have loaded the core babel library first, then the loader, and finally 2 plugins or presets to work specifically with React and all the new ES2015 and ES6 onwards code.

Moving on, let’s add some code and let’s get the webpack configuration started.

This is how the package.json file should look after all the installations so far. You might have a different version number depending on when you are following this article.

The Code

Let’s start by adding a webpack.config.js file in the root of our application structure. Add the following code in your webpack.config file.

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  //This property defines where the application starts
  entry:'./src/index.js',

  //This property defines the file path and the file name which will be used for deploying the bundled file
  output:{
    path: path.join(__dirname, '/dist'),
    filename: 'bundle.js'
  },

  //Setup loaders
  module: {
    rules: [
      {
        test: /\.js$/, 
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader'
        }
      }
    ]
  },

  // Setup plugin to use a HTML file for serving bundled js files
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html'
    })
  ]
}

Okay so let’s understand the lines above.

First we start by requiring the default path module to access the file location and make changes to the file location.

Next we require the HTMLWebpackPlugin to generate an HTML file to be used for serving bundled JavaScript file/files. Read more about HTMLWebpackPlugin by clicking the link.

Then we have the export.module object with some properties in them. The first one is the entry property, which is used to specify which file webpack should start with to get the internal dependency graph created.

module.exports = {
  entry:'./src/index.js'
}

Next up is the output property specifying where the bundled file should be generated and what the name of the bundled file would be. This is done by the output.path and output.filename properties.

module.exports = {
  //This property defines the file path and the file name which will be used for deploying the bundled file
  output:{
    path: path.join(__dirname, '/dist'),
    filename: 'bundle.js'
  },
}

Next up are the loaders. This is to specify what webpack should do for a specific type for file. Remember that webpack out of box only understands JavaScript and JSON, but if your project has any other language used, this would be the place to specify what to do with that new language.

module.exports = {
  //Setup loaders
  module: {
    rules: [
      {
        test: /\.js$/, 
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader'
        }
      }
    ]
  }
}

The information should be specified in an object for each module property, which further has an array of rules. There will be an object for every case. I have also specified to exclude everything in my node_modules folder.

Next up is the plugin property. This is used to extend the capabilities of webpack. Before a plugin can be used in the plugin array inside the module exports object, we need to require the same.

module.exports = {
  // Setup plugin to use a HTML file for serving bundled js files
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html'
    })
  ]
}

This particular plugin, as explained earlier, will use the specified file in our src folder. It’ll then use that as a template for our HTML file where all the bundled files will be automatically injected. There are a lot of other out of the box plugins that we could use — checkout the official page for more information.

The last thing we need to do is create a .babelrc file to use the babel preset we installed and take care of the ES6 classes and import statements in our code. Add the following lines of code to the .babelrc file.

{
  "presets": ["env", "react"]
}

And just like that, now babel will be able to use those presets. Okay so enough of the setup — let’s add some React code to see how this works.

React Code

Since the starting point for the application is the index.js file in src folder, let’s start with that. We will start by requiring both React and ReactDOM for our use in this case. Add the below code in your index.js file.

import React from 'react';
import ReactDOM from 'react-dom';
import App from './Components/App';

ReactDOM.render(<App />, document.getElementById('app'));

So we simply import another file from our components folder, which you will create, and add another file in the folder called App.js. So let’s see what’s inside the App.js file:

import React, { Component } from 'react'

class App extends Component {
  render() {
    return (
      <div>
        <h1>Webpack + React setup</h1>
      </div>
    )
  }
}

export default App;

We are almost done. The only thing left now is to enable hot reloading. This means that every time a change is detected, the browser auto reloads the page and has the ability to build and bundle the entire application when the time comes.

We can do this by adding script values in the package.json file. Remove the test property in the scripts object of your package.json file and add these two scripts:

"start": "webpack-dev-server --mode development --open --hot",
"build": "webpack --mode production"

You are all set! Go to your terminal, navigate to the root folder, and run npm start. It should start a dev server on your computer and serve the HTML file in your browser. If you make any minor/major changes and save the code, your browser will be automatically refreshed to show the latest set of changes.

Once you think you are ready to get the app bundled, you just need to hit the command, npm build, and webpack will create an optimised bundle in your project folder which can be deployed on any web server.

Conclusion

This is just a small application or use case of webpack and babel, but the applications are limitless. I hope you are excited enough to explore more options and ways of doing things with webpack and babel. Please refer to their official websites to know more and read in depth.

I have created a Github repo with all the code in it, so please refer to it incase of any questions.

ashishcodes4/webpack-react-setup
_Setting a react application from scratch without using CLI - ashishcodes4/webpack-react-setup_github.com

My two cents about webpack? Well, at times you may think that it’s nothing more than a tool, and why should you bother too much for a tool? But trust me when I say this: the initial struggle while learning your way around webpack will save you an enormous number of hours you would otherwise invest developing without webpack.

That’s all for now, hope to be back with yet another interesting article very soon. I hope you have enjoyed reading this one!

In case you face any difficulty or issues while following any of the above mentioned steps/processes, please feel free to get in touch and leave comments.

LinkedIn: https://www.linkedin.com/in/ashish-nandan-singh-490987130/

Twitter: https://twitter.com/ashishnandansin

]]> <![CDATA[ How to build modern applications with WEBPACK ]]> https://www.freecodecamp.org/news/how-to-build-modern-applications-with-webpack-c81ccf6dd54f/ 66d460f63a8352b6c5a2ab0d Wed, 09 Jan 2019 19:01:17 +0000 By Samuel Omole

How far can we get with Webpack’s default configuration?

I had the privilege of speaking at GDG Devfest last month with a talk that was centered around using webpack in our modern day applications. You can check out the slides here.

Daily, I get to work as an Engineer and/or consultant with amazing and fast-paced teams, and webpack seems like the recurring factor throughout these teams (we use ReactJs for most of our applications). Initially, my talk was supposed to focus on using webpack with frontend frameworks/libraries like ReactJS, Vue, Angular etc.

Before submitting my proposal, I decided to run a mini survey to know what people thought about webpack. To my surprise, a lot of people labeled webpack as “Only used with frameworks” which was far from the truth. Still others said that “setting up webpack was daunting”. This led me to focus more on using webpack with Vanilla JS and seeing how far we could go with webpack’s default configuration.

But first:

WHAT IS WEBPACK?

Image

I personally define webpack as a tool that takes many Javascript modules and merges them into one Javascript module that can be sent off to the browser.

I know, it’s an oversimplification of what webpack does, but people seem to understand it. To explain more, webpack is a bundler that looks for Javascript modules with dependencies (basically, Javascript files that need code from other Javascript files), squashes them together, and then produces a Javascript file or files that have no dependencies. That way they can easily be shipped to the browser.

History of Webpack

To understand the problems that webpack tries to solve, we need to know a little bit about the history of webpack itself. To keep this section very short, I’ve just outlined two important tools and one concept:

  • Google Web Toolkit: This is a framework from Google that converts Java to Javascript (I know, right?). It has one feature that seems to be my personal favorite feature in webpack which is “code splitting”. (I will explain code splitting in a subsequent article.)
  • Modules_Webmake: This is the library that webpack originates from. It’s essentially a tool that allows us to organize our Javascript files for the browser the same way we do for NodeJS (awesome).
  • IIFE: means immediately invoked function expression. This is basically a Javascript function that is called or invoked the same time as it was created.

Immediately Invoked Function Expression

I broke this into its own section because I had to explain further. This is an example of an IIFE:

Image

If we were to place this function in our script tag, this would run immediately. The script tag is loaded by the browser. It’s kind of equivalent to attaching a function to window.onload but with an added advantage.

Because of the way closures work in Javascript, all the variables that were declared in the IIFE are scoped within that function. This means I wouldn’t have issues like namespace clashes in my codebase but at the same time, I still have access to the functions exposed by the IIFE.

Why Webpack?

So, what are the problems we face today that webpack helps us solve?

First, we have the issue of script tags. I have worked on a codebase where each HTML page has at the very least 30 script tags arranged in a very precise order. I know some might say that isn’t really an issue, but the browser will have to make one request per file which can hurt your “time to load”. Also the script tags can get hard to manage, where rearranging just one could break the application (I tried that ?).

Second, we still have the issue of namespacing where the global namespace can get cluttered. I know we are very creative people especially when it comes to naming variables, but then when you work on a larger team there are times where the variable names just clash with each other. Or even your future self might think of the same name again (yeah it happens).

I know some organizations that make it habit for their developers to always keep their variables within the scope of their function, but we can’t always rely on that (or on _this_). In the end, it just makes separation of concern difficult.

Third, remember I mentioned that webpack originated from modules_webmake. Because webpack allows us to organize our files the same way we do in NodeJS (using CommonJS), we have the added benefit of writing modular code which scales really well (just ask people that use frontend frameworks).

CommonJS

Image

I won’t explain too much about CJS as this isn’t the point of the article. But you can say it’s a JS module system used in NodeJS.

Webpack allows us to use this module and even the “better” ES module system in the browser without any issue (Webpack handles it in a smart way). This helps us write really modular and maintainable code where a JS file can handle a single functionality (Single Responsibility Principle).

ES Modules (ESM)

Image

This is another module system that, believe it or not, is already implemented by current browsers. But unfortunately, it has it’s limitations there. Webpack also allows us to use this module with no issue (as webpack still converts it in the end), but I found that using ESM makes most codebases I have worked on more readable. I would have loved to dive deeper into this but that isn’t the aim of this article. For a better explanation I would recommend this amazing article.

How does Webpack work?

I know I said earlier that Webpack is magic but I lied. To put it as simply as possible:

  • Webpack takes a path to a single entry point, which is a JS file, and looks for import statements (it could either be ESM or CJS).
  • It then traverses the imported file, also looking for more import statements, while it creates a dependency graph in the process.

To explain better, take a look at the image:

Image J.K.

I have two files there, index.js and helpers.js These two files perform different functions, but I am importing and using the function in helpers.js in my index.js file. By default, Webpack’s entry point is ./src/index.js and from there it tries to build the dependency graph as shown below:

Image

How to get started

To get a better understanding of how webpack works, we are going to build a simple TODO app. It will have just the basic add and delete functionality and we are going to bundle it using Webpack’s default configuration (so no webpack config file). This is what the app will look like:

Image J.K.

The first step is to create a new project directory and create two folders, a folder named dist and another named src . By default, Webpack’s entry point is the path ./src/index.js and it outputs the bundled JS into ./dist/main.js — that’s why we are creating the two folders.

In the dist folder you can create the index.html file. This is not necessary for webpack as the file can be placed anywhere within the project directory and you can just make reference to the main.js file. In the end, your project structure should look like this:

Image

In the src folder we will create the index.html file where we will start the implementation of our TO-DO app’s functionalities. But first, let’s populate the index.html file. Since creating a TO-DO app isn’t part of this tutorial I will just show the code below:

<html>
  <head>
    <title>Todo App</title>
  </head>
  <body>
    <div class="container">
      <p>
        <label for="new-task">Add Item</label>
        <input id="new-task" type="text">
        <button id="addTask">Add</button>
      </p>

      <h3>Todo</h3>
      <ul id="tasks">
      </ul>
    </div>
    <script src="main.js"></script>
  </body>
</html>

Let us now make it functional. We are going to break the two functions (Add and Delete) into their own files and then import them into index.js . We will create two files in our src folder named addTask.js and deleteTask.js . Your project structure should now look like this:

Image

We can now start adding the necessary logic, so let’s implement the deleteTask.js first because it has no dependencies. Paste this in your deleteTask.js file:

const deleteTask = function(e) {
  console.log("Delete Task...", e);
  //Remove the parent list item from the ul
  var listItem = e.target.parentNode;
  var ul = listItem.parentNode;
  ul.removeChild(listItem);
};


export default deleteTask;

All that is going on in that file is we are creating the deleteTask function and then exporting it as a default export.

We can now implement the addTask function. In the addTask.js file add the following code:

import deleteTask from "./deleteTask";


const createNewTaskElement = function(taskString) {

  const listItem = document.createElement("li");
  const label = document.createElement("label");
  const deleteButton = document.createElement("button");
deleteButton.innerText = "Delete";
  deleteButton.className = "delete";
  deleteButton.addEventListener("click", deleteTask);

    label.innerText = taskString;
    listItem.appendChild(label);
      listItem.appendChild(deleteButton);
    return listItem;
};


const addTask = function(e) {
  const taskList = document.getElementById("tasks");
  const task = document.getElementById("new-task");
  if (task.value !== "") {
    const newTaskItem = createNewTaskElement(task.value);
    taskList.appendChild(newTaskItem);
    task.value = "";
  }
};


export default addTask;

In this one, we first of all import the deleteTask.js file. By default, if no extension is specified in the import, webpack automatically assumes that it’s a .js file. Then we have the function that creates the list item containing the task that was entered in the form. The only thing to note is that we are attaching the delete function to the click handler of the delete button. Then we create the actual addTask function and export it.

We will then need to import our addTask function into index.js . Paste the code below into your index.js file:

import addTask from './addTask';

const addTaskButton = document.getElementById("addTask");

addTaskButton.addEventListener("click", addTask);

This is pretty straightforward: we are importing the addTask function and attaching it to the click handler for the addTaskButton . If you followed the steps above you should be good to go.

Finally, to get our main.js file we need to run Webpack through our codebase. For this step, make sure you have NodeJS installed on your system, then we will install webpack globally using this command:

npm install -g webpack OR sudo npm install -g webpack

Once it’s done installing run the following command:

webpack

It will bundle up our file successfully but we should see a warning in the terminal like this:

Image

Webpack is just warning us that we didn’t specify a mode. We could leave it as is and run the code, everything should work fine. But if you don’t like the warning then you can run Webpack like this:

webpack --mode=development

And you’re good to go.

Wrapping up

If you got lost along the way you can always use the GitHub repo for reference (It has some CSS styling in it, though).

I hope this article was able to show you what Webpack has to offer (just the basics, with no configuration whatsoever). In subsequent articles, I will try to show how to set up various custom configurations for features like code splitting, lazy loading and configuring Webpack to work with multi-page applications.

In order to keep this article as basic as possible, I avoided the use of a package.json file in the article. The use of a package.json file and installing webpack locally is the most scalable way of using webpack and I will go into it in my next article on using Webpack.

To help navigate the coming articles, it will really help if you can drop a comment of what you would like to see explained or implemented regarding Webpack. ??

I will like to especially thank Sean T. Larkin, Israel Obiagba and Hassan Sani for their feedback in making the article better than initially planned. You all rock!

]]> <![CDATA[ How to create a Vue.js app using Single-File Components, without the CLI. ]]> https://www.freecodecamp.org/news/how-to-create-a-vue-js-app-using-single-file-components-without-the-cli-7e73e5b8244f/ 66d46177d1ffc3d3eb89de7e Tue, 04 Dec 2018 20:48:42 +0000 An understanding of Vue’s single-file components (SFCs) and Node Package Manager (NPM) will be helpful for this article.

A framework’s command line interface, or CLI, is the preferred method to scaffold a project. It provides a starting point of files, folders, and configuration. This scaffolding also provides a development and build process. A development process provides a way to see updates occurring as you edit your project. The build process creates the final version of files to be used in production.

Installing and running Vue.js (“Vue”) can be done with a script tag that points to the Vue content delivery network (CDN). No build or development process is necessary. But, if you use Vue single-file components (SFCs), you need to convert those files into something the browser can understand. The files need to be converted to Hyper-Text Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript (JS). In this case, a development and build process must be used.

Instead of relying on the Vue CLI to scaffold our project and provide us with a development and build process, we will build a project from scratch. We will create our own development and build process using Webpack.

What is Webpack?

Webpack is a module bundler. It merges code from multiple files into one. Before Webpack, the user included a script tag for each JavaScript file. Although browsers are slowly supporting ES6 modules, Webpack continues to be the preferred way to build modular code.

Besides being a module bundler, Webpack can also transform code. For example, Webpack can take modern JavaScript (ECMAScript 6+) and convert it into ECMAScript 5. While Webpack bundles the code itself, it transforms the code with loaders and plugins. Think of loaders and plugins as add-ons for Webpack.

Webpack and Vue

Single-file components allow us to build an entire component (structure, style, and function) in one file. And, most code editors provide syntax highlighting and linting for these SFCs.

Image

_[Vue Single File Component](https://vuejs.org/v2/guide/single-file-components.html" rel="noopener" target="blank" title="): notice the .vue extension.

Notice the file ends with .vue. The browser doesn’t know what to do with that extension. Webpack, through the use of loaders and plugins, transforms this file into the HTML, CSS, and JS the browser can consume.

The Project: Build a Hello World Vue Application Using Single-File Components.

Step 1: Create the project structure

The most basic Vue project will include an HTML, JavaScript, and a Vue file (the file ending in .vue). We will place these files in a folder called src. The source folder will help us separate the code we are writing from the code Webpack will eventually build.

Since we will be using Webpack, we need a Webpack configuration file.

Additionally, we will use a compiler called Babel. Babel allows us to write ES6 code which it then compiles into ES5. Babel is one of those “add-on features” for Webpack. Babel also needs a configuration file.

Finally, since we are using NPM, we will also have a node_modules folder and a package.json file. Those will be created automatically when we initialize our project as an NPM project and begin installing our dependencies.

To get started, create a folder called hello-world. From the command line, change to that directory and run npm init. Follow the on-screen prompts to create the project. Then, create the rest of the folders (except for node_modules) as described above. Your project structure should look like this:

Image

The simplest Vue SFC project structure.

Step 2: Install the dependencies

Here is a quick rundown of the dependencies we are using:

vue: The JavaScript framework

vue-loader and vue-template-compiler: Used to convert our Vue files into JavaScript.

webpack: The tool that will allow us to pass our code through some transformations and bundle it into one file.

webpack-cli: Needed to run the Webpack commands.

webpack-dev-server: Although not needed for our small project (since we won’t be making any HTTP requests), we will still “serve” our project from a development server.

babel-loader: Transform our ES6 code into ES5. (It needs help from the next two dependencies.)

@babel/core and @babel/preset-env: Babel by itself doesn’t do anything to your code. These two “add-ons” will allow us to transform our ES6 code into ES5 code.

css-loader: Takes the CSS we write in our .vue files or any CSS we might import into any of our JavaScript files and resolve the path to those files. In other words, figure out where the CSS is. This is another loader that by itself won’t do much. We need the next loader to actually do something with the CSS.

vue-style-loader: Take the CSS we got from our css-loader and inject it into our HTML file. This will create and inject a style tag in the head of our HTML document.

html-webpack-plugin: Take our index.html and inject our bundled JavaScript file in the head. Then, copy this file into the dist folder.

rimraf: Allows us, from the command line, to delete files. This will come in handy when we build our project multiple times. We will use this to delete any old builds.

Let’s install these dependencies now. From the command line, run:

npm install vue vue-loader vue-template-compiler webpack webpack-cli webpack-dev-server babel-loader @babel/core @babel/preset-env css-loader vue-style-loader html-webpack-plugin rimraf -D

Note: The “-D” at the end marks each dependency as a development dependency in our package.json. We are bundling all dependencies in one file, so, for our small project, we have no production dependencies.

Step 3: Create the files (Except for our Webpack configuration file).

<template>
  <div id="app">
    {{ message }}
  </div>
</template>

<script>
export default {
  data() {
    return {
      message: 'Hello World',
    };
  },
};
</script>

<style>
#app {
  font-size: 18px;
  font-family: 'Roboto', sans-serif;
  color: blue;
}
</style>

<html>
  <head>
    <title>Vue Hello World</title>
  </head>
  <body>
    <div id="app"></div>
  </body>
</html>

import Vue from 'vue';
import App from './App.vue';

new Vue({
  el: '#app',
  render: h => h(App),
});

module.exports = {
  presets: ['@babel/preset-env'],
}

Up to this point, nothing should look too foreign. I’ve kept each file very basic. I’ve only added minimal CSS and JS to see our workflow in action.

Step 4: Instructing Webpack what to do

All the configuration Webpack needs access to is now present. We need to do two final things: Tell Webpack what to do and run Webpack.

Below is the Webpack configuration file (webpack.config.js). Create this file in the projects root directory. Line-by-line we’ll discuss what is occurring.

const HtmlWebpackPlugin = require('html-webpack-plugin');
const VueLoaderPlugin = require('vue-loader/lib/plugin');

module.exports = {
  entry: './src/main.js',
  module: {
    rules: [
      { test: /\.js$/, use: 'babel-loader' },
      { test: /\.vue$/, use: 'vue-loader' },
      { test: /\.css$/, use: ['vue-style-loader', 'css-loader']},
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
    }),
    new VueLoaderPlugin(),
  ]
};

Lines 1 and 2: We are importing the two plugins we use below. Notice, our loaders don’t normally need to be imported, just our plugins. And in our case, the vue-loader (which we use in line 9) also needs a plugin to work (however, Babel, for example, does not).

Line 4: We export our configuration as an object. This gives us access to it when we run the Webpack commands.

Line 5: This is our entry module. Webpack needs a place to start. It looks in our main.js file and then starts to comb through our code from that point.

Line 6 and 7: This is the module object. Here, we primarily pass in an array of rules. Each rule tells Webpack how to handle certain files. So, while Webpack uses the entry point of main.js to start combing through our code, it uses the rules to transform our code.

Line 8 (rule): This rule instructs Webpack to use the babel-loader on any files which end with .js. Remember, Babel will transform ES6+ to ES5.

Line 9 (rule): This rule instructs Webpack to use vue-loader (and don’t forget the associated plugin on line 17) to transform our .vue files into JavaScript.

Line 10 (rule): Sometimes we want to pass a file through two loaders. Counterintuitively, Webpack will pass the file from right to left instead of left to right. Here we are using two loaders and saying to Webpack: “get my CSS from my Vue file or any JavaScript files(css-loader) and inject it into my HTML as a style tag (vue-style-loader).

Lines 11 and 12: Close out our rules array and module object.

Lines 13: Create a plugins array. Here we will add the two plugins we need.

Line: 14 -16 (plugin): The HtmlWebpackPlugin takes the location of our index.html file and adds our bundled JavaScript file to it via a script tag. This plugin will also copy the HTML file to our distribution folder when we build our project.

Line 17 (plugin): The VueLoaderPlugin works with our vue-loader to parse our .vue files.

Line 18: Close out the plugins array.

Line 19: Close out the Webpack object that we are exporting.

Step 5: Setting up our package.json file so we can run Webpack

Our configuration is complete, now we want to see our application. Ideally, as we make changes to our application, the browser would update automatically. This is possible with webpack-dev-server.

Delete the test script in our package.json file, and replace it with a script to serve our application:


{
  "name": "hello-world",
  "version": "1.0.0",
  "description": "",
  "main": "main.js",
  "scripts": {
    "serve": "webpack-dev-server --mode development"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@babel/core": "^7.1.6",
    "@babel/preset-env": "^7.1.6",
    "babel-loader": "^8.0.4",
    "css-loader": "^1.0.1",
    "html-webpack-plugin": "^3.2.0",
    "rimraf": "^2.6.2",
    "vue": "^2.5.17",
    "vue-loader": "^15.4.2",
    "vue-style-loader": "^4.1.2",
    "vue-template-compiler": "^2.5.17",
    "webpack": "^4.26.0",
    "webpack-cli": "^3.1.2",
    "webpack-dev-server": "^3.1.10"
  },
  "dependencies": {}
}

The name of this command is your choice. I chose to call mine serve since we will be serving our application.

From our terminal or command line, we can run npm run serve and that in turn will run webpack-dev-server --mode development .

The --mode development is what’s called a flag or option. We haven’t talked about this, but it essentially instructs Webpack that you are in development mode. We can also pass in --mode production which we will do when we build our project. These aren’t necessarily required for Webpack to work. Without these, you will get a warning message telling you to provide a mode when you run Webpack .

I say “necessarily required” because Webpack will minimize our code in production mode but not in development. So, don’t think those commands don’t do anything–they do.

Let’s run npm run serve and see what happens.

When we run npm run serve we get some output in our terminal. And, if everything goes well:

Image

And if we scroll up a bit:

Image

Point your browser to http://localhost:8080. You will see your Blue Hello World message in Roboto font.

Image

Now, let’s update the project and change the message to Hello Universe. Notice that the webpage refreshes automatically. That’s great, right? Can you think of a downside?

Let’s change the application just a bit and include an input which we will bind a variable to (with v-model). We will output the variable in an <h2>tag below the input. I’ve also updated the styling section to style the message now. Our App.vue file should look like this:

<template>
  <div id="app">
    <input
      v-model="message"
      type="text">
      <h2 class="message">{{ message }}</h2>
  </div>
</template>

<script>
export default {
  data() {
    return {
      message: 'Hello world!',
    };
  },
};
</script>

<style>
.message {
  font-size: 18px;
  font-family: 'Roboto', sans-serif;
  color: blue;
}
</style>

When we serve our application, we will have an input with a message of Hello World below it. The input is bound to the message variable, so as we type, we change the <h2> content. Go ahead, type into the input to change the <h2>content.

Now go back to your editor, and below the <h2>tag, add the following:

<h3>Some Other Message</h3>

Save your App.vue and watch what happens.

The h2 we just updated by typing in our input reverted back to Hello World. This is because the browser actually refreshes, and the script tag and page are loaded again. In other words, we were not able to maintain the state of our application. This may not seem like a big deal, but as you are testing your application and adding data to it, it will be frustrating if your app “resets” every time. Fortunately, Webpack offers us a solution called Hot Module Replacement.

The hot module replacement is a plugin provided by Webpack itself. Up until this point, we have not used the Webpack object itself in our configuration file. However, we will now import Webpack so we can access the plugin.

In addition to the plugin, we will pass one additional option to Webpack, the devServer option. In that option, we will set hot to true. Also, we will make an (optional) update to our build workflow: We will open the browser window automatically when we run npm run serve. We do this by setting open to true which is also inside the devServer option.

const HtmlWebpackPlugin = require('html-webpack-plugin');
const VueLoaderPlugin = require('vue-loader/lib/plugin');
const webpack = require('webpack');

module.exports = {
  entry: './src/main.js',
  module: {
    rules: [
      { test: /\.js$/, use: 'babel-loader' },
      { test: /\.vue$/, use: 'vue-loader' },
      { test: /\.css$/, use: ['vue-style-loader', 'css-loader']},
    ]
  },
  devServer: {
    open: true,
    hot: true,
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
    }),
    new VueLoaderPlugin(),
    new webpack.HotModuleReplacementPlugin(),
  ]
};

Notice that we’ve imported Webpack so we could access the hotModuleReplacementPlugin. We’ve added that to the plugins array, and then told Webpack to use it with hot: true. We open the browser window automatically when we serve the application with open: true.

Run npm run serve:

Image

The browser window should open, and if you open your dev tools, you should notice a slight change in the output. It now tells us hot module replacement is enabled. Let’s type in our input to change the <h2> content. Then, change theh3 tag to read: One More Message.

Save your file and notice what happens.

The browser doesn't refresh, but our <h3>change is reflected! The message we typed in the input remains, but the h3 updates. This allows our application to keep it’s state while we edit it.

Step 7: Building our project

So far, we’ve served our application. But, what if we want to build our application so we can distribute it?

If you noticed, when we serve our application, no files are created. Webpack creates a version of these files that only exist in temporary memory. If we want to distribute our Hello World app to our client, we need to build the project.

This is very simple. Just like before, we will create a script in our package.json file to tell Webpack to build our project. We will use webpack as the command instead of webpack-dev-server. We will pass in the --mode production flag as well.

We will also use the rimraf package first to delete any previous builds we may have. We do this simply by rimraf dist.

_dist_ is the folder Webpack will automatically create when it builds our project. “Dist” is short for distribution–i.e. we are “distributing” our applications code.

The rimraf dist command is telling the rimraf package to delete the dist directory. Make sure you don’t rimraf src by accident!

Webpack also offers a plugin that will accomplish this cleaning process called clean-webpack-plugin. I chose dist show an alternative way.

Our package.json file should look like this:

{
  "name": "hello-world",
  "version": "1.0.0",
  "description": "",
  "main": "main.js",
  "scripts": {
    "clean": "rimraf dist",
    "build": "npm run clean && webpack --mode production",
    "serve": "webpack-dev-server --mode development"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@babel/core": "^7.1.6",
    "@babel/preset-env": "^7.1.6",
    "babel-loader": "^8.0.4",
    "css-loader": "^1.0.1",
    "html-webpack-plugin": "^3.2.0",
    "rimraf": "^2.6.2",
    "vue": "^2.5.17",
    "vue-loader": "^15.4.2",
    "vue-style-loader": "^4.1.2",
    "vue-template-compiler": "^2.5.17",
    "webpack": "^4.26.0",
    "webpack-cli": "^3.1.2",
    "webpack-dev-server": "^3.1.10"
  },
  "dependencies": {}
}

There are three things to notice:

  1. I’ve created a separate clean script so we can run it independently of our build script.

  2. npm run build will call the independent clean script we’ve created.

  3. I have && between npm run clean and webpack. This instruction says: “run npm run clean first, then run webpack”.

Let’s build the project.

npm run build

Webpack creates a dist directory, and our code is inside. Since our code makes no HTTP requests, we can simply open our index.html file in our browser and it will work as expected.

If we had code that was making HTTP requests, we would run into some cross-origin errors as we made those requests. We would need to run that project from a server for it to work.

Let’s examine the index.html that Webpack created in the browser and the code editor.

Image

R

If we open it in our editor or take a look at the source code in our dev tools you will see Webpack injected the script tag. In our editor though, you won’t see the styles because the style tag is injected dynamically at runtime with JavaScript!

Also, notice our development console information is no longer present. This is because we passed the --production flag to Webpack.

Conclusion

Understanding the build process behind the frameworks you use will help you to better understand the framework itself. Take some time to try to build an Angular, React or another Vue Project without the use of the respective CLIs. Or, just build a basic three-file site (index.html, styles.css, and app.js), but use Webpack to serve and build a production version.

Thanks for reading!

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

]]> <![CDATA[ How to combine Webpack 4 and Babel 7 to create a fantastic React app ]]> daniel odame / 66d45d652472e5ed2fa07ba5 Thu, 11 Oct 2018 21:21:57 +0000 By Adeel Imran

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

I previously wrote an article called “How to conquer Webpack 4 and build a sweet React app.” Soon after I wrote the article, babel swooped in with a major breaking change and many of the packages got deprecated. So I decided to write a new tutorial.

I will focus on setting up webpack with react which will have .scss support along with code splitting

The purpose for writing this again is simple: I want everyone to feel comfortable. Because setting up webpack can be really daunting. Especially for new developers out there. Follow along, and what seemed difficult and maybe scary will seem like a piece of cake.

Before we start, here is the source code. I know this has loads of things in it. I plan to use the same code base to talk about webpack, react, SCSS, hot module replacement, testing with jest and enzyme, linting code, and adding a code formatter like prettier in other articles to come, so I will continuously keep on updating this code base. I will not bloat this code base — I promise.

Note: If you feel like making a PR for the repository, you are more than welcome :) So let’s get started.

For simplicity sake, this article is only going to focus on;

  • Setting up Webpack 4 with Babel 7 for React
  • Support for .SCSS
  • Code Splitting
  • Development environment with HMR (Hot Module Replacement)
  • Production configuration
  • Dividing your Webpack configuration into chunks
  • Handling staging, demo, production, test and other environments in code
  • Generating a visualizer in production build to check which chunk of code took how much size and what are the dependencies of the chunks. Super useful.

Prerequisite

You need to have node installed in order to use npm (node package manager).

First things first, create a folder called app then open up your terminal and go into that app folder and type:

npm init -y

This will create a package.json file for you.

Second create a folder called src in your app folder. Inside app/src create a file called index.js and write the following code.

console.warn('I am a Star Trek nerd');
console.log('So through out this tutorial, you will see a lot of Star Trek quotes');
console.log('Starting now');
console.log("Compassion: that’s the one thing no machine ever had. Maybe it’s the one thing that keeps men ahead of them. -Dr McCoy");

You can write anything above of course. I chose Star Trek.

Image Change is the essential process of all existence. — Spock

Next we need to install a couple of dependencies. You can just copy the dependencies & devDependencies from the package.json below into your own and do an **npm install**:

{
  "name": "react-boiler-plate",
  "version": "1.0.0",
  "description": "A react boiler plate",
  "main": "src/index.js",
  "author": "Adeel Imran",
  "license": "MIT",
  "scripts": {
    "start": "a script will come here"
  },
  "dependencies": {
    "react": "^16.5.2",
    "react-dom": "^16.5.2"
  },
  "devDependencies": {
    "@babel/core": "^7.0.0",
    "@babel/plugin-proposal-class-properties": "^7.0.0",
    "@babel/plugin-proposal-export-namespace-from": "^7.0.0",
    "@babel/plugin-proposal-throw-expressions": "^7.0.0",
    "@babel/plugin-syntax-dynamic-import": "^7.0.0",
    "@babel/polyfill": "^7.0.0-beta.51",
    "@babel/preset-env": "^7.0.0-beta.51",
    "@babel/preset-react": "^7.0.0-beta.51",
    "babel-loader": "^8.0.0-beta.0",
    "copy-webpack-plugin": "^4.5.1",
    "css-loader": "^0.28.11",
    "html-webpack-plugin": "^3.2.0",
    "mini-css-extract-plugin": "^0.4.3",
    "node-sass": "^4.8.3",
    "optimize-css-assets-webpack-plugin": "^4.0.0",
    "sass-loader": "^7.0.3",
    "style-loader": "^0.21.0",
    "uglifyjs-webpack-plugin": "^1.2.5",
    "webpack": "^4.12.0",
    "webpack-cli": "^3.0.8",
    "webpack-dev-server": "^3.1.4",
    "webpack-merge": "^4.1.3",
    "webpack-visualizer-plugin": "^0.1.11"
  }
}

Yes I know, I know! That’s a lot to create a hello world react app. But wait, this is all you will need. Even if you want to create a enterprise level app. (Maybe one or two more things depending on your requirements, but this is the backbone for it.)

So let’s talk about each and everyone of them before we dive deep into the code.

webpack: We need Webpack to bundle our code.

webpack-cli: We will be using some CLI features of Webpack to make our lives easier while writing some scripts.

webpack-dev-server: I will create a server using the webpack-dev-server package. This is only meant to be used in the development environment, and not for production. This means while developing and working on my code, I don’t need a separate server like NodeJS to setup manually.

webpack-merge: To divide our configuration into chunks, more on this later

webpack-visualizer-plugin: To see a visual representation of each of our bundle size — how much space they are taking and what are their dependencies.

style-loader: This adds CSS to the DOM by injecting a <script /> tag in the header

sass-loader: For SCSS support

node-sass: A dependency for sass-loader

css-loader: To convert our .scss files into .css

mini-css-extract-plugin: This plugin extracts CSS into separate files. It creates a CSS file per JS file which contains CSS.

uglifyjs-webpack-plugin: To minify JavaScript code for production

optimize-css-assets-webpack-plugin To minify CSS code for production

html-webpack-plugin: This does more then generate an HTML file, it supports on demand .css and .js files automatically added to your HTML files on demand

copy-webpack-plugin: Copies files/folders to your build folder.

babel-loader: This is the loader that helps webpack compile .js files

@babel/core: Babel core compiler, this is a dependency that lets you use babel-loader

@babel/preset-react Babel preset for React code

@babel/preset-env: Babel preset that allows you to use the latest JavaScript

@babel/pollyfill: Babel includes a polyfill that includes a custom regenerator runtime and core-js. This will emulate a full ES2015+ environment. This means support for async/await type of cool syntax sugar.

Up till now this is pretty much what I wrote in How to conquer Webpack 4 and build a sweet React app.

So what changed?

Well! Babel introduced a breaking change (for the greater good, believe me) which you can read more here: Removing Babel’s Stage Preset. What this meant was that before if you included babel-preset-stage-2 let’s say, it would include all proposals related to stage-2, which would bloat your code. But you just might need one specific feature of stage-2.

So in order to combat this, babel deprecated all those preset plugins and shipped individual features. You now have to set those up manually. Cool right? So let’s talk a bit about those individual packages and what they do.

@babel/plugin-proposal-class-properties: Coverts your class syntax into a function for browsers that don’t support class syntax

@babel/plugin-proposal-export-namespace-from Supports syntax like import * as ns from '../path/to/module';

@babel/plugin-proposal-throw-expressions New syntax to throw exceptions from within an expression context. I love this feature :D

@babel/plugin-syntax-dynamic-import This is what helps with code splitting. Webpack ships with code splitting by default (Since webpack 1). But when you want to code split in webpack while you are using babel, then you need to use this plugin.

Note: for this tutorial you won’t need@babel/plugin-proposal-export-namsespace-from & @babel/plugin-proposal-throw-expressions

Also here is a list of all babel plugins. I mean all of them. Check out the list here.

And now that you know why we need what we need — nothing extra — you’ll feel more confident implementing the webpack configuration.

Let’s start by adding a .babelrc file in the root of out app folder:

{
  "presets": [
    "@babel/preset-env",
    "@babel/preset-react"
  ],
  "plugins": [
    "@babel/plugin-syntax-dynamic-import",
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-export-namespace-from",
    "@babel/plugin-proposal-throw-expressions"
  ]
}

We have 2 main presets preset-env & preset-react . The rest are our plugins to add “wings” to our code.

And to quote Captain Kirk from Star Trek (because why not):

Perhaps man wasn’t meant for paradise. Maybe he was meant to claw, to scratch all the way. Captain Kirk

In his defense, Captain Kirk was up against the likes of General Change, Khan, The Borg and so many dangerous foes. All we are up against is the beautiful Webpack and Babel. So perhaps we developers are meant for paradise.

So let’s set our webpack up.

Create a config folder in your app . If you feel lost you can at any time refer to the GitHub repository for this. Now inside our config folder let’s create a file called webpack.base.config.js The reason I call this base is because it is going to be used for our development and for production. Because why write the same thing twice? Again if this isn’t making much sense, just bear with me a few more minutes.

In your config/webpack.base.config.js write this: 

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader'
        }
      },
    ]
  }
}

Once you have it in place, run this command in your root app directory. (I’ll tell you what this command does a bit later with the code we wrote above, I promise.)

$ node_modules/.bin/webpack-dev-server --mode development --config config/webpack.base.config.js --open --hot --history-api-fallback

Once you run this command, you will see this screen:

Image Oh! A Fancy Error!

So what happened here? Well when we ran the webpack command, it did find our index.js file that we wrote earlier in app/src/index.js — but it didn’t have a .html to run it in. So let’s create an index.html file in our app/src folder:

<!DOCTYPE HTML>

<html>

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <base href="/">
  <title>Tutorial</title>
</head>

<body>
  <div id="app"></div>
</body>

</html>

Let’s update our webpack.base.config.js as well:

var HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader'
        }
      }
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({ 
      template: './src/index.html', 
      filename: './index.html' 
    })
  ]
}

Let’s run that command again now:

$ node_modules/.bin/webpack-dev-server --mode development --config config/webpack.base.config.js --open --hot --history-api-fallback

Your browser will open up. If you are using Google Chrome, press ctrl+shift+j and your browser console will open up. You will see something like this:

Image Hey look at that, this is what I wrote in my console! You should see something like this at your end as well.

So let’s talk what happened here. Our webpack.base.config.js has two main things: modules and plugins. A module can have multiple rules, and each rule is applied to certain file type. The certain file type that we want to apply that rule to is in test of that rule:

rules: [      
  {        
    test: /\.js$/,        
    exclude: /node_modules/,        
    use: {          
      loader: 'babel-loader'        
    }      
  },    
]

Here by saying test: /\.js$./, we are telling webpack to apply this rule only for .js files. The other thing is exclude which also takes in a regex expression of what not not to include. This is where we tell it not to compile node_modules because this will compile all of it, and there are loads of dependencies installed. Check the node_modules yourself. The last part is use.

Now webpack knows where to apply the rule using test and where not to apply the rule using exclude — but what is the rule exactly? That is where use comes into play: here we specify loader: 'babel-loader'. Now what babel-loader does is that it looks for .babelrc file that we wrote earlier. And all the presets & plugins we wrote there. It takes all of them and applies those to our .js files.

Which brings us to the next question: how does Webpack 4 find those files? Well Webpack 4 ships with loads of default stuff already set up for you. Two of those are entry and output .

entry point by default is the src directory that we wrote in our app folder.

output point is where all the compiled bundled code is generated, which is going to be dist folder in out app folder. (You won’t see that now, because we haven’t compiled our code yet for production.)

Next we’ll talk about html-webpack-plugin The purpose of this plugin is simple as the name suggests. It creates HTML files to serve all of your bundled files. (All of it — .js, .css, .scss, .img etc)

Image If you have followed along up till yet. You guys are great

Let’s talk about when we run the following:

$ node_modules/.bin/webpack-dev-server --mode development --config config/webpack.base.config.js --open --hot --history-api-fallback

This command will open up port [http://localhost:8080](http://localhost:8080) or another port if 8080 is taken. (I’ll talk more about what this command does later — for now let’s move on).

The index.html that is generated looks like this:

Image I simply clicked ctrl + shift + i this opened up the inspect element in my chrome browser

Blue part: The blue part is simply where I put in my meta tags and defined a title for the app.

Yellow part: The yellow part highlighted is the hard coded part that we wrote in our **index.html** file. This is where our future React app will reside.

Red Part: The part I underlined in red is the most interesting part. We never wrote this in our index.html file, so where did it come from?

Webpack is very smart. It took that file in your **index.js** , bundled it all up nicely, and added it up all neatly in the file called **main.js** . Then it injected it in our **index.html** file. Super Cool!

We are almost 60% done! Believe me the hard part is over…

Let’s Add React

The cool thing is, all our dependencies are already installed. And everything is already configured. So in your app/src/index.js remove all the code and replace it with this:

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

const App = () => {
  return (
    <div>
      <p>
        We are a most promising species, Mr. Spock, as predators go. Did you know that? I frequently
        have my doubts. I dont. Not any more. And maybe in a thousand years or so, we will be able
        to prove it.
      </p>
      <p>- Captain Kirk</p>
    </div>
  );
};

ReactDOM.render(<App />, document.getElementById('app'));

Now if your terminal is still running the webpack-dev-server script, just check the browser out. If not, here is the script. I don’t want you to scroll all the way up again.

$ node_modules/.bin/webpack-dev-server --mode development --config config/webpack.base.config.js --open --hot --history-api-fallback

This is what you will see:

Image This is our React application live.

Now make sure you don’t close the terminal, and go in your app/src/index.js and make some changes to your <App /> component. Try changing the sentence in the paragraph. Once changed, go back to your browser and the content is already there updated. How cool is that? :D

This sums up 70% of our tutorial — only 30% more to go. You are doing great.

Let’s Add SCSS Support

Let’s start by updating our config/webpack.base.config.js by adding another rule for .scss files

var HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader'
        }
      },
      {
        test: /\.scss$/,
        use: [
          'style-loader',
          'css-loader',
          'sass-loader'
        ]
      },
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
      filename: './index.html'
    }),
  ]
}

So the use I use here takes an array instead of an object like what I did for the .js files. This is because we need to apply a set of rules here:

use: [ 'style-loader','css-loader','sass-loader' ]

So let’s read the use array from right to left — this is important. What we are telling Webpack is to take any .scss files it finds and parse it for its own understanding using the sass-loader. Once it has converted it into sass, we then ask Webpack to convert the sass into CSS. For that we apply css-loader.

As of this point we have converted the .scss into .css. But there is no way for us to add the converted files into our .html. For this we use the last loader called style-loader which takes all the converted .css and injects it into our index.html file.

So let’s add some .scss to test this out. In your src/ folder add a file called myStyles.scss Mine looks like the one below:

body {
  background-color: skyblue;
  color: black;
}

.app {
  width: 450px;
  margin: 0 auto;
  padding-top: 50px;
}

And my src/index.js file looks like this:

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

import './myStyles.scss';;

const App = () => {
  return (
    <div className="app">
      <p>
        We are a most promising species, Mr. Spock, as predators go. Did you know that? I frequently
        have my doubts. I dont. Not any more. And maybe in a thousand years or so, we will be able
        to prove it.
      </p>
      <p>- Captain Kirk</p>
    </div>
  );
};

ReactDOM.render(<App />, document.getElementById('app'));

Restart your webpack-dev-server by running this command again:

$ node_modules/.bin/webpack-dev-server --mode development --config config/webpack.base.config.js --open --hot --history-api-fallback

This was the last time I’ll make you manually write that script up. After this we will move this command into our scripts section in our package.json.

Your browser will open up, this is what it looks like now:

Image Nice! huh.

Now in your myStyles.scss file, try making some changes. Like make the font-size: white; come back to your browser. It reflects those changes. You don’t have to restart your server again — just for the .scss to compile.

With this, most of our development configuration is done. Our React application is live, and has hot module replacement for .js files as well as .scss files

So before we move further, let’s add the webpack-dev-server script in our package.json. In your **scripts** section, add the following code:

"scripts": {
    "start": "webpack-dev-server --mode development --config config/webpack.base.config.js --open --hot --history-api-fallback --env.PLATFORM=local --env.VERSION=stag",
    "prebuild": "webpack --mode production --config config/webpack.prod.config.js --env.PLATFORM=production --env.VERSION=stag --progress",
    "build": "node server",
},

For now I’ll talk about the start command. I’ll talk about the prebuild and build scripts later in the production configuration section.

So what does this command do: npm run start

"start": "webpack-dev-server --mode development --config config/webpack.base.config.js --open --hot --history-api-fallback"

Let’s break this down. When we run npm run start we’re telling it to run a package called webpack-dev-server. Then we pass it some configurations.

  • webpack-dev-server serves a webpack app and updates the browser on changes.
  • --mode development tells webpack to compile the code in development mode. This is basically to make the compilation time faster.
  • --config config/webpack.base.config.js So by default if you have webpack.config.js file in your root app folder, you don’t have to supply the --config flag to it. But since I want to explicitly add all my webpack related configurations in the config folder, I pass in --config option that tells webpack where to look for the configuration
  • --open command opens the browser, when webpack is done with its compilation.
  • --hot flag tells webpack to actively watch for code changes in the src folder. If any changes happen, it reloads the browser.
  • --history-api-fallback This option enables History API Fallback support in webpack-dev-server, effectively asking the server to fallback to index.html in the event that a requested resource cannot be found.
  • --env.PLATFORM & --env.VERSION are custom flags that I pass in my configuration (more on this later).

Now that we are done, let move onto our production configurations.

But before we do that, let’s talk about webpack-merge. Now this is a real winner. It takes in one configuration and another one and merges them both together to give us one. The way it works is you need to wrap your configuration with merge like the one below. Let’s start off by making our webpack.base.config.js file into a webpack-merge usable chunk:

const webpack = require('webpack');
const merge = require("webpack-merge");

const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = env => {
  const { PLATFORM, VERSION } = env;
  return merge([
      {
        module: {
          rules: [
            {
              test: /\.js$/,
              exclude: /node_modules/,
              use: {
                loader: 'babel-loader'
              }
            },
            {
              test: /\.scss$/,
              use: [
                'style-loader',
                'css-loader',
                'sass-loader'
              ]
            }
          ]
        },
        plugins: [
          new HtmlWebpackPlugin({
            template: './src/index.html',
            filename: './index.html'
          }),
          new webpack.DefinePlugin({ 
            'process.env.VERSION': JSON.stringify(env.VERSION),
            'process.env.PLATFORM': JSON.stringify(env.PLATFORM)
          }),
        ],
    }
  ])
};

Previously where we where exporting an object, now we are exporting a function which returns merge and takes in the configuration.

Let’s break this down as to what this is doing.The first thing we talk about is this:

module.exports = function(env) {}

The new flags added in our start command — env.PLATFORM=local — env.VERSION=stag are passed to our webpack configurations, which we can access with the env param in module.exports = function (env) {}. So what can we do with this?

  • We can set up a conditional statement in our webpack configuration, that if a certain condition is met, then do this or that (more on this later). Basically we will change our configuration on compile time to cater to whichever environment is being run — production or development.
  • The other thing that we can do here is pass them in our code as well. So what do I mean by pass in our code? One new plugin I added for this is called **new webpack.DefinePlugin**. (Also that is why I had to include webpack at the top of webpack.base.config.js.) What this does is: “The DefinePlugin allows you to create global constants which can be configured at compile time.” You can read more about this here.

Next we return a configuration inside the function like this:

return merge({ 
   // our webpack configuration here
});

Well not much has changed here. All we did was wrap our configuration in merge. This gives us the ability to merge this entire configuration into the other one that we will create.

One thing added is a new plugin called DefinePlugin which I already talked about.

If you are a nerd like me and want to dig deeper into webpack-merge I suggest you dive in here — this was developed by the cool folks at [**SurviveJS**](https://survivejs.com/).

Before moving to the production settings, let’s check if our base configurations are working.

In your src/index.js file add this somewhere:

console.log('process.env.VERSION', process.env.VERSION);

console.log('process.env.PLATFORM', process.env.PLATFORM);

console.log('process.env.NODE_ENV', process.env.NODE_ENV);

In your terminal run npm run start. Wait for your browser to load up. Open up your terminal.

Image Click ctrl+shift+j to open up the console in your browser

The first two you see in the console is the result of us passing the --env flags from our script to our webpack configuration and setting it with DefinePlugin. The third one is with the --mode flag that we pass in our script. If mode is development or production, then that is set up in our process.env.NODE_ENV flag.

Now that that’s cleared up, let’s move on.

In your config folder, create a new file called webpack.prod.config.js and add the following code into it as shown below:

var merge = require('webpack-merge');

// Plugins
var OptimizeCssAssetsPlugin = require('optimize-css-assets-webpack-plugin');
var UglifyJsPlugin = require('uglifyjs-webpack-plugin');
var Visualizer = require('webpack-visualizer-plugin');

var baseConfig = require('./webpack.base.config');

const prodConfiguration = env => {
  return merge([
    {
      optimization: {
        runtimeChunk: 'single',
        splitChunks: {
          cacheGroups: {
            vendor: {
              test: /[\\/]node_modules[\\/]/,
              name: 'vendors',
              chunks: 'all'
            }
          }
        },
        minimizer: [new UglifyJsPlugin()],
      },
      plugins: [
        new OptimizeCssAssetsPlugin(),
        new Visualizer({ filename: './statistics.html' })
      ],
    },
  ]);
}

module.exports = env => {
  return merge(baseConfig(env), prodConfiguration(env));
}

Let’s start from the bottom with module.exports = env => {}

We merge two configurations: one is our baseConfig and the other is prodConfiguration . The --env flags we pass in our scripts are passed on as an object in the env => {} params in our function. We then pass them onto both the baseConfig & prodConfig.

So what is prodConfig ?

It is basically a list of the optimizations we want to perform when our code goes up for production.

The optimization.minimizer takes in a new UglifyJsPlugin. What this does is uglify and minify our .js files.

The optimization.splitChunks actually takes all of your common code and creates a vendor.bundle.js file. It is not going to make one now. But as our code base grows, we have multiple routes, and there are different modules being used like date-fns moment lodash material-ui etc. It will take all the common code from entire app and make a common file called vendor.bundle.js . This way, the repeated code isn’t used again & again. (I am against this approach, but for educational purposes I described it here.)

Going forward I’ll comment the optimization.splitChunks but, it will exist there in the code repository if you want to use it. You just have to uncomment this section. I prefer to split my code based on routes. Having common code chunked out into a separate module means that your entire common code is going to be loaded first. This can be huge, and as a result the user’s first time interaction will take longer (because now all of these dependencies are being loaded, which might not need to be in the respective page that the user is seeing/viewing).

Next up, we have a couple of plugins. One of them happens to be new OptimizeCssAssetsPlugin(). All it does is take all of our generated .css and minify/optimize it. This doesn’t work right now, because we are using style-loader and style loader directly injects the generated .css into the DOM.

First, we need tell webpack to extract all the generated .css into a separate file, and then the optimizations added by this plugin are applied. (We’ll do this a bit later.)

The other plugin added here is called new Visualizer({ filename: ‘./statistics.html’ }) .This plugin is awesome: it generates a statistics.html file in the dist/ folder for you. Open the file, and you’ll see a graphic like the one below.

Image _Image taken from [https://github.com/chrisbateman/webpack-visualizer](https://github.com/chrisbateman/webpack-visualizer" rel="noopener" target="blank" title=")

Right now we only have a single module called main.js. But with time, as we add more modules, and have code splitting added to it. More modules will start showing up here and we can actually see what modules take what size. This can be really useful when you are trying to reduce the size of your application.

Coming back to OptimizeCssAssetsPlugin() . In order to optimize the .css generated, we need to move this into a separate module. For that I am going to use mini-css-extract-plugin This will require us to make changes in both of our webpack files, the .base and .prod files.

// webpack.base.config.js
const webpack = require('webpack');
const merge = require("webpack-merge");

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = env => {
  const { PLATFORM, VERSION } = env;
  return merge([
      {
        module: {
          rules: [
            {
              test: /\.js$/,
              exclude: /node_modules/,
              use: {
                loader: 'babel-loader'
              }
            },
            {
              test: /\.scss$/,
              use: [
                PLATFORM === 'production' ? MiniCssExtractPlugin.loader : 'style-loader',
                'css-loader',
                'sass-loader'
              ]
            }
          ]
        },
        plugins: [
          new HtmlWebpackPlugin({
            template: './src/index.html',
            filename: './index.html'
          }),
          new webpack.DefinePlugin({ 
            'process.env.VERSION': JSON.stringify(env.VERSION),
            'process.env.PLATFORM': JSON.stringify(env.PLATFORM)
          }),
        ],
    }
  ])
};

// webpack.prod.config.js
/* eslint-disable */
const merge = require('webpack-merge');
// Plugins
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const OptimizeCssAssetsPlugin = require('optimize-css-assets-webpack-plugin');
const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
const Visualizer = require('webpack-visualizer-plugin');
// Configs
const baseConfig = require('./webpack.base.config');

const prodConfiguration = env => {
  return merge([
    {
      optimization: {
        // runtimeChunk: 'single',
        // splitChunks: {
        //   cacheGroups: {
        //     vendor: {
        //       test: /[\\/]node_modules[\\/]/,
        //       name: 'vendors',
        //       chunks: 'all'
        //     }
        //   }
        // },
        minimizer: [new UglifyJsPlugin()],
      },
      plugins: [
        new MiniCssExtractPlugin(),
        new OptimizeCssAssetsPlugin(),
        new Visualizer({ filename: './statistics.html' })
      ],
    },
  ]);
}

module.exports = env => {
  return merge(baseConfig(env), prodConfiguration(env));
}

Let’s talk about the changes I made in webpack.base.config.js .Only one module was added called const MiniCssExtractPlugin = require(“mini-css-extract-plugin”);. Then in our .scss rules we checked if the PLATFORM flag passed has the value production. If so, we add MiniCssExtractPlugin.loader, and otherwise we add the style-loader.

style-loader is used to actively watch and change our compiled .css in development mode, while MiniCssExtractPlugin.loader is used when we need to extract that generated CSS into a separate module. This is only for production.

In the other file webpack.prod.config.js we have these two plugins added:

new MiniCssExtractPlugin(),
new OptimizeCssAssetsPlugin(),

The first will extract this into a separate module called main.css and the other will minify/uglify the generated CSS.

Having done this, we are almost 90% done. If you have stayed this far, kudos to you.

Image Awesome!

Before we proceed further, here is what Captain Kirk has to say

You know the greatest danger facing us is ourselves, and irrational fear of the unknown. There is no such thing as the unknown. Only things temporarily hidden, temporarily not understood.

  • James T. Kirk, The Corbomite Maneuver

Let’s add more functionality, to our code. Now there are two ways to add files in your code. One is by using another loader called file-loader which will help you add files of any type into your .js files like we did with .scss files.

I want to talk about another approach here, because I think assets like fonts, images and others should be loaded in parallel rather than in your .js files. This helps provide a better experience for the user. So for that propose we will load our images statically.

For this we will use a plugin called copy-webpack-plugin. The best thing about all this is you already have this installed. In your webpack.base.config.js add another plugin, like the below:

const CopyWebpackPlugin = require('copy-webpack-plugin'); // Add this in top

module.exports = env => {
  return merge([
      {
        module: {},
        plugins: [
          new CopyWebpackPlugin([ { from: 'src/static' } ]), // Add this in the plugins section
        ],
    }
  ])
};

The copy-webpack-plugin takes in an argument called from. This tells the plugin where to locate the static files and then copy them in the dist folder. Here I am telling it to look for a folder called src/static and copy all of its content in the dist/ folder.

Once you have added this and set it up, all you have to do is, in your app/src folder, create a new folder called static . In this folder, create another folder called images so your folder will have a directory like this: app/src/static/images

I am going to put an image here called header.jpg, but you can call it whatever you like. This is the image I am using: https://unsplash.com/photos/Idi6I490p7I (Photo by Felix Mittermeier on Unsplash).

Now in order for this to work, you need to run the npm run prebuild command (I’ll talk more about npm run prebuild & npm run build later when we set up our NodeJS server with ExpressJS) because we need our static files to be copied. The npm run start command won’t copy this to the dist/ folder because it doesn’t compile code to the dist/ folder.

Once you have run the npm run prebuild command this is what you will see:

Image As you can see we have a images folder and inside that folder we have header.jpg file

So how can we access this file in our code?

I am going to make some changes in my index.js file along with myStyles.scss .You can follow along as well — we’re just adding an <img /> along with some .scss

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

import './myStyles.scss';

const App = () => {
  return (
    <div className="app">
      <img alt="header" src="/dist/images/header.jpg" className="app-header" />
      <p>
        We are a most promising species, Mr. Spock, as predators go. Did you know that? I frequently
        have my doubts. I dont. Not any more. And maybe in a thousand years or so, we will be able
        to prove it.
      </p>
      <p>- Captain Kirk</p>
    </div>
  );
};

ReactDOM.render(<App />, document.getElementById('app'));

body {
  background-color: skyblue;
  color: black;
}

.app {
  width: 450px;
  margin: 0 auto;
  padding-top: 50px;

  & .app-header {
    height: 250px;
    width: inherit;
    object-fit: cover;
  }
}

The only thing to note here is in the index.js file where I add an image:

<img    
  alt="header"   
  src="/dist/images/header.jpg"
  className="app-header"
/>

The main thing is the path we give in the src.

Once you have added this, let’s check how this looks in the browser. Go and run npm run start command.

Image Hey! Look Ma! I added an image. With this added, our webpack configuration is done.

Let’s recap what we have accomplished so far

  • Setting up Webpack 4 with Babel 7 for React
  • Support for .SCSS
  • Development environment with HMR [For both .js & .scss]
  • Production configuration
  • Dividing your Webpack configuration into chunks
  • Generating a visualizer in production build to check which chunk of code is how big and what are the dependencies of the chunks. Super useful.
  • Support for static files

Things We Still Need To Accomplish

  • Add support for async/await in our code
  • Create a NodeJS server using ExpressJS for our production build
  • Code Splitting

Let’s start with async/await first. For this purpose I am going to make a smart <App /> component. Inside this component I am going to call an API that gets me information about Captain Kirk, because he is awesome. So in our index.js add the following code:

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

import './myStyles.scss';

class App extends React.Component {
  state = {
    CaptainKirkBio: {},
  };

  componentDidMount() {
    this.onGetKirkBio();
  }

  onGetKirkBio = async () => {
    try {
      const URL = 'http://stapi.co/api/v1/rest/character/search';
      const result = await fetch(URL, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/x-www-form-urlencoded',
        },
        body: {
          title: 'James T. Kirk',
          name: 'James T. Kirk',
        },
      });
      const resultJSON = await result.json();
      const character = resultJSON.characters[0];
      this.setState({ CaptainKirkBio: character });
    } catch (error) {
      console.log('error', error);
    }
  };

  render() {
    const { CaptainKirkBio } = this.state;
    return (
      <div className="app">
        <img alt="header" src="/dist/images/header.jpg" className="app-header" />
        <p>
          We are a most promising species, Mr. Spock, as predators go. Did you know that? I
          frequently have my doubts. I dont. Not any more. And maybe in a thousand years or so, we
          will be able to prove it.
        </p>
        <p>- Captain Kirk</p>
        <section>
          {Object.values(CaptainKirkBio).length === 0 ? (
            <p>Loading User Information</p>
          ) : (
            <p style={{ wordBreak: 'break-all' }}>{JSON.stringify(CaptainKirkBio)}</p>
          )}
        </section>
      </div>
    );
  }
}

ReactDOM.render(<App />, document.getElementById('app'));

All I am doing here is calling an API using try/catch async/await and getting information about Captain Kirk. Simple right? This should work. Let’s fire this up in the browser.

Run the command:

npm run start

Image Our app crashed here! Wonder why?

If you hit ctrl+shift+j your console will open up, and you will see an error there called **regeneratorRuntime** . So what is this error and how do we get rid of it?

This error gets thrown when the browser doesn’t support async/await or generators for that matter.

But Adeel! That’s the only reason we are using babel right?

Yes! Here’s what Henry Zhu, the awesome dude behind babel, has to say about this:

If you are using generators/async and the environment doesn’t support it natively we compile using regenerator which uses a runtime. So you’ll have to include regeneratorRuntime either yourself or use babel-polyfill.

Reference taken from an issue.

Now you know why this exists, so let’s solve it. We need to make some changes to our webpack.base.config.js:

const path = require('path');
const webpack = require('webpack');
const merge = require("webpack-merge");

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const HtmlWebpackPlugin = require('html-webpack-plugin');
const CopyWebpackPlugin = require('copy-webpack-plugin');

const APP_DIR = path.resolve(__dirname, '../src'); // <===== new stuff added here

module.exports = env => {
  const { PLATFORM, VERSION } = env;
  return merge([
      {
        entry: ['@babel/polyfill', APP_DIR], // <===== new stuff added here
        module: {
          rules: [
            {
              test: /\.js$/,
              exclude: /node_modules/,
              use: {
                loader: 'babel-loader'
              }
            },
            {
              test: /\.scss$/,
              use: [
                PLATFORM === 'production' ? MiniCssExtractPlugin.loader : 'style-loader',
                'css-loader',
                'sass-loader'
              ]
            }
          ]
        },
        plugins: [
          new HtmlWebpackPlugin({
            template: './src/index.html',
            filename: './index.html'
          }),
          new webpack.DefinePlugin({ 
            'process.env.VERSION': JSON.stringify(env.VERSION),
            'process.env.PLATFORM': JSON.stringify(env.PLATFORM)
          }),
          new CopyWebpackPlugin([ { from: 'src/static' } ]),
        ],
    }
  ])
};

Check line no.8 and line no.14 in the snippet added above.

By default Webpack 4 takes in entry point of src/. But if we want to have multiple entry points, we can customize the entry point as well. In my entry point I am just telling it two things:

entry: ['@babel/polyfill', APP_DIR],
  • @babel/polyfill Babel plugin that includes a polyfill that includes a custom regenerator runtime and core-js.
  • APP_DIR the path to our src/ folder which I wrote on line no.8 const APP_DIR = path.resolve(__dirname, ‘../src’); All this line is doing is pointing to the path of src/ folder in our app/ folder.

So the entry just takes in “points” as to what to compile.

Now that this is cleared up, let’s run the npm run start command again.

Image Our async/await method is working. Great :D

So far so good!

Now that everything is set up, let’s create a NodeJS server using ExpressJS.

Image In the immortal words of Khan Noonien Singh

The first thing we have to install is Express, so in your terminal write this:

npm install express --save

Or if you use yarn (like I do):

yarn add express

Next in the root app folder create a new folder called server. Inside the folder create a index.js file like the one shown below:

const express = require('express');
const path = require('path');
const http = require('http');

const app = express();

// Point static path to dist
app.use('/', express.static(path.join(__dirname, '..', 'dist')));
app.use('/dist', express.static(path.join(__dirname, '..', 'dist')));

const routes = require('./routes');

app.use('/', routes);

/** Get port from environment and store in Express. */
const port = process.env.PORT || '3000';
app.set('port', port);

/** Create HTTP server. */
const server = http.createServer(app);
/** Listen on provided port, on all network interfaces. */
server.listen(port, () => console.log(`Server Running on port ${port}`));

Let’s discuss this code before we proceed further.

We instantiate our app with express() and then set up a static public folder called **dist**. This is the same folder created by Webpack when we run our production command.

We include our **routes** file — we will create that in a second — and set the **routes** file to the / directory.

Next we set up a port. If none is provided via the node CLI, we use port 3000. After that, we create an HTTP server and listen on that server via the port. At the very last, we console to our terminal that we are running the server on that certain port.

Let’s create our last file called **routes/index.js**:

const path = require('path');
const router = require('express').Router();

router.get('*', (req, res) => {
  const route = path.join(__dirname, '..', '..', 'dist', 'index.html');
  res.sendFile(route);
});

module.exports = router;

Here we check that whatever the user comes on, the path redirects the user to the **dist/index.html** where our React application lives.

And that’s it. We are done.

Now go in your terminal and type:

npm run build

This will take a moment. It will show you the progress while it compiles. After that, it consoles a message that it is listening to port 3000 if no port is provided.

Now go to your browser http:localhost:3000/ and your application is alive.

Since we are at it, let’s talk in detail about what npm run prebuild and npm run build do.

Basically if we write the word pre for a script, in this case prebuild, every time we run our command npm run build it will first execute npm run prebuild and then run the script npm run build .

All npm run build does is run node server/index.js (You don’t have to write /index.js) in the command. NodeJS is smart enough to know it needs to run the index.js inside the server folder.

This sums up our NodeJS application setup as well.

One last topic to go. I’ll give a very brief overview on code splitting, and how you can achieve it.

Code Splitting

At the start of this tutorial, we added @babel/plugin-syntax-dynamic-import This gives us the ability to lazily load our code inside our application.

Inside my src/ folder, I am going to create a component called Foo.js which looks something like this.

import React from 'react';

export default () => (
  <div>
    <p>I am Foo! Pleasure to meet you.</p>
  </div>
);

Nothing special about Foo here.

The special thing starts when we include this component in our src/index.js file.

You might be thinking something like this:

import Foo from './Foo';
class App extends React.Component {
   state = {};
   render() {
      return (
        <div>
          <p>I am App</p>
          <Foo />
        </div>
      )
   }
}

Well no, for a dynamic import we have to do this:

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

import './myStyles.scss';

class App extends React.Component {
  state = {
    CaptainKirkBio: {},
    Foo: null, // Foo is out component
  };

  componentDidMount() {
    this.onGetKirkBio();
    import(/* webpackChunkName: 'Foo' */ './Foo').then(Foo => {
      this.setState({ Foo: Foo.default });
    });
  }

  onGetKirkBio = async () => {
    try {
      const result = await fetch('http://stapi.co/api/v1/rest/character/search', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/x-www-form-urlencoded',
        },
        body: {
          title: 'James T. Kirk',
          name: 'James T. Kirk',
        },
      });
      const resultJSON = await result.json();
      const character = resultJSON.characters[0];
      this.setState({ CaptainKirkBio: character });
    } catch (error) {
      console.log('error', error);
    }
  };

  render() {
    const { CaptainKirkBio, Foo } = this.state;
    return (
      <div className="app">
        <img alt="header" src="/dist/images/header.jpg" className="app-header" />
        <p>
          We are a most promising species, Mr. Spock, as predators go. Did you know that? I
          frequently have my doubts. I dont. Not any more. And maybe in a thousand years or so will
          be able to prove it.
        </p>
        <p>- Captain Kirk</p>
        <section>
          {Object.values(CaptainKirkBio).length === 0 ? (
            <p>Loading User Information</p>
          ) : (
            <p style={{ wordBreak: 'break-all' }}>{JSON.stringify(CaptainKirkBio)}</p>
          )}
        </section>
        {Foo ? <Foo /> : <p>Foo is loading</p>}
      </div>
    );
  }
}

ReactDOM.render(<App />, document.getElementById('app'));

Things to note here are in line 9 line 14, 15, 16 line 40 line 57:

  • Line 9: We Set Foo as null
  • Line 14, 15, 16 : As soon as our component mounts, we import our <Foo /> component

Let’s talk more about this:

import(/* webpackChunkName: 'Foo' */ './Foo').then(Foo => {     
   this.setState({Foo: Foo.default });    
})

Let’s break this down even more.

import(/* webpackChunkName: ‘Foo’ */ ‘./Foo’) : This has 2 parts to it, we set a chunk name called Foo in /* webpackChunkName: ‘Foo’ */. You can call this whatever you want. What this does is when your application loads the ./Foo file, it will get loaded by the name of Foo as defined in /* webpackChunkName: ‘Foo’ */

Image /* webpackChunkName: ‘Foo’ */ Try changing Foo to something else in the /* */ comment

This feature is called magic comments in webpack, because it’s lets you name the file when you load it in your code.

The other part of import(/* webpackChunkName: ‘Foo’ */ ‘./Foo’) is the ‘./Foo’ at the very end of the statement. This is the path from where we include our file.

This returns us a promise .then(Foo => {}). Since our export of <Foo /> was export default when we set our state of Foo we set it to this.setState({Foo: Foo.default }); in order to assign the Foo component to the state variable Foo.

line 57 : This is where we display our <Foo /> component. Unless it is not loaded i.e, it is null, we show a loading message. And once we have the &lt;Foo /> component we show it.

And that, my friends, is code splitting.

I really do hope this was helpful for you. If it was please do let me know so that I can write more stuff like this. You can always reach me out on Twitter and again if you followed along till the end, I am really proud of you guys. YOU GUYS ARE ROCKING IT!

Image

This article was originally published in Freecodecamp publication previously on Medium. Read here

]]> <![CDATA[ How to use ReactJS with Webpack 4, Babel 7, and Material Design ]]> https://www.freecodecamp.org/news/how-to-use-reactjs-with-webpack-4-babel-7-and-material-design-ff754586f618/ 66c355cad372f14b49bdcb62 Wed, 10 Oct 2018 16:06:50 +0000 By Nazare Emanuel Ioan

For the past year and some, I have been working with React at Creative Tim. I have been using create-react-app for developing some nice products. There have been a lot of clients asking how can someone migrate our product templates on Webpack.

So after a number of requests, we created this little tutorial about how to start using React with Webpack 4 and Babel 7. At the end of the tutorial, I am going to show you guys how to add Material Dashboard React on top of the newly created app.

Before we get started please make sure you have the latest versions of npm and Nodejs installed globally on your machine. At the time of writing this post, the latest versions were 6.4.1 for npm and 8.12.0 (lts) for Nodejs on my machine.

Creating a new project folder with package.json

First things first, let’s create a new folder for our new app and enter it:

mkdir react-webpack-babel-tutorialcd react-webpack-babel-tutorial

Now that we have created the folder in which we are going to develop the app, we need to add a package.json file to it. We can do this two ways and you should choose one of them:

  1. just create the package.json file without any other configuration:
npm init -y

As you can see, the package.json file has been created with some very basic information in it.

Image

Image npm init -y output

  1. create the package.json file with some extra config settings
npm init

I’ve added some stuff to our newly created package.json file, such as some nice keywords, a repo and so on…

Image

Image npm init output

After this, let’s add an index.html and index.js files to our new project folder, inside an src folder.

  1. Linux/MacOS commands
mkdir srctouch src/index.htmltouch src/index.js
  1. Windows commands
mkdir srcecho "" > src\index.htmlecho "" > src\index.js

After this, let’s add the following template inside the index.html.

<!DOCTYPE html><html lang="en">  <head>    <meta charset="utf-8">    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">    <meta name="theme-color" content="#000000">    <title>React Tutorial</title>  </head>  <body>    <noscript>      You need to enable JavaScript to run this app.    </noscript>    <div id="root"></div>    <!--      This HTML file is a template.      If you open it directly in the browser, you will see an empty page.      You can add webfonts, meta tags, or analytics to this file.      The build step will place the bundled scripts into the <body> tag.    -->  </body></html>

Let’s add something inside the index.js just for the sake of some showcase that we are going to see a bit further down.

(function () {  console.log("hey mister");}());

And this is what we’ve got so far:

Image folder project structure

Adding Webpack to the project

Let’s start adding all the Webpack packages that we are going to need. We are going to install them as devDependencies since they will be only used in development mode.

npm install --save-dev webpack webpack-cli webpack-dev-server
  • webpack
  • used to configure our new app
  • at the time of this post, the version was 4.19.0
  • webpack-cli
  • used so that we can use Webpack in the command line
  • at the time of this post, the version was 3.1.0
  • webpack-dev-server
  • used so that when we make a change to a file inside our new app, we won’t need to refresh the page. It refreshes the browser page automatically every time we change a file in our app
  • as its name says, it’s a server that is working non-stop
  • at the time of this post, the version was 3.1.8

Image npm install — save-dev webpack webpack-cli webpack-dev-server output

If we take a look inside the package.json file, we are going to see that these three packages were added to this file like so:

"devDependencies": {  "webpack": "^4.19.0",  "webpack-cli": "^3.1.0",  "webpack-dev-server": "^3.1.8"}

I’m going to go ahead and delete the ^ (caret) from each version. This is because I can’t tell whether the next version of these plugins is still going to work with what I am building. I think this is something that should be common sense. When creating a new app, use the available versions and then, maybe make some updates to newer versions. You might not know what a new version will break in your app.

As you will see, the installation of these plugins made some changes to our project folder. It added node_modules folder and package-lock.json to it.

Image project folder after installing webpack

Now, we need to add a new file to our project, the config file for Webpack called webpack.config.js:

  1. Linux/MacOS command
touch webpack.config.js
  1. Windows command
echo "" > webpack.config.js

Or you can simply manually create the new file if you do not want to use the command line.

Before we go ahead and start messing with the Webpack config file, let’s first install some stuff that we are going to need in our app.

First, we are going to work with some paths inside the Webpack config file. Let’s install path in our project as a devDependency.

npm install --save-dev path

Also, since we don’t want to manually inject the index.js file inside the HTML one, we are going to need a plugin called html-webpack-plugin. This plugin will inject the index.js inside the HTML file without any manual operation.

npm install --save-dev html-webpack-plugin

Once again, I am going to edit my package.json file and delete all the ^ (caret) occurrences from it.

One more edit that we are going to make to our package.json is to add some new scripts inside the scripts object, after the test script (See the second example below).

"webpack": "webpack","start": "webpack-dev-server --open"

This is what your package.json should look like at this point:

{  "name": "react-webpack-babel-tutorial",  "version": "1.0.0",  "description": "This is a Tutorial to showcase the usage of React with Webpack and Babel",  "main": "index.js",  "scripts": {    "test": "echo \"Error: no test specified\" && exit 1",    "webpack": "webpack",    "start": "webpack-dev-server --open"  },  "repository": {    "type": "git",    "url": "git+https://github.com/creativetimofficial/react-webpack-babel-tutorial.git"  },  "keywords": [    "react",    "webpack",    "babel",    "creative-tim",    "material-design"  ],  "author": "Creative Tim &lt;hello@creative-tim.com> (https://www.creative-tim.com/)",  "license": "MIT",  "bugs": {    "url": "https://github.com/creativetimofficial/react-webpack-babel-tutorial/issues"  },  "homepage": "https://github.com/creativetimofficial/react-webpack-babel-tutorial#readme",  "devDependencies": {    "html-webpack-plugin": "3.2.0",    "path": "0.12.7",    "webpack": "4.19.0",    "webpack-cli": "3.1.0",    "webpack-dev-server": "3.1.8"  }}

Let’s go ahead and run these commands one by one and see what happens.

npm run webpack

Webpack will automatically take the src/index.js file, compile it, and output it inside dist/main.js and will minify that code. This is because we haven’t yet configured the Webpack config file. Also, since we haven’t configured the file, we are going to have some warnings in our console.

Image

Image

Image npm run webpack output

If we run the other command

npm start

webpack-dev-server will automatically start a server and open the default browser with this server. But once again, since we do not have our webpack.config.js file configured, the output will not be the expected one.

Image

Image npm start output

If you want to stop the server, just press at the same time the CTRL + C keys while in the command line.

Let’s add the following template inside our Webpack config file:

const path = require('path');const HtmlWebpackPlugin = require('html-webpack-plugin');module.exports = {  entry: path.join(__dirname,'src','index.js'),  output: {    path: path.join(__dirname,'build'),    filename: 'index.bundle.js'  },  mode: process.env.NODE_ENV || 'development',  resolve: {    modules: [path.resolve(__dirname, 'src'), 'node_modules']  },  devServer: {    contentBase: path.join(__dirname,'src')  },  plugins: [    new HtmlWebpackPlugin({      template: path.join(__dirname,'src','index.html')    })  ]};
  • entry and output
    — these are used to tell our server what has to be compiled and from where (entry: path.join(__dirname,’src’,’index.js’),). It also tells where to put the outputted compiled version (output — the folder and the filename)
  • mode
    — this is the mode of our output. We are setting it to ‘development’. If in the scripts we specify the NODE_ENV variable, it will take that one instead. See the below example on how to use NODE_ENV (note that the below changes will not be made inside the package.json file in this tutorial, it is just an example for you to see how it works)
"webpack": "NODE_ENV=production webpack",
  • resolve
    — this is used so that we can import anything from src folder in relative paths instead of absolute ones. It is the same for the node_modules. We can import anything from node_modules directly without absolute paths
  • devServer
    — this tells the webpack-dev-server what files are needed to be served. Everything from our src folder needs to be served (outputted) in the browser
  • plugins
    — here we set what plugins we need in our app. As of this moment we only need the html-webpack-plugin which tells the server that the index.bundle.js should be injected (or added if you will) to our index.html file

If we now run the earlier commands we will see some differences.

npm run webpack

Image

Image

Image npm run webpack output with webpack.config.js

We’ve changed where the output should be (from dist folder to build folder). By changing the mode of Webpack, now the code has a different look. It is not minified as the last time with no config.

npm start

Image

Image

Image npm start output with webpack.config.js

The webpack-dev-server took everything from the src folder and outputted it to our browser.

We are on the right path, but we’ve only added Webpack to our project. Where are React and Babel? Well, that is what we are going to do next.

React, Babel and some nice loaders for styles

Add React and ReactDOM to our project as normal dependencies.

npm install --save react react-dom

At this moment in our development, if we were to add React code inside our JS file, Webpack will give us an error. It doesn’t know how to compile React inside the bundle.js file.

Let’s modify the index.js file as follows:

import React from "react";import ReactDOM from "react-dom";let HelloWorld = () => {  return <h1>Hello there World!</h1>}ReactDOM.render(  <HelloWorld/>,  document.getElementById("root"));

And after that let’s start the server again.

npm start

And this is the error:

Image

Image webpack error for not having appropriate loaders for react

So this is where Babel comes to our aid. Babel will tell Webpack how to compile our React code.

Let’s go ahead and add a bunch of Babel packages to our app as devDependencies.

npm install --save-dev @babel/core @babel/node @babel/preset-env @babel/preset-react babel-loader
  • @babel/core
    — this is used to compile ES6 and above into ES5
  • @babel/node
    — this is used so that we can import our plugins and packages inside the webpack.config.js rather than require them (it’s just something that I like, and maybe you’ll like it too)
  • @babel/preset-env
    — this will determinate which transformations or plugins to use and polyfills (i.e it provides modern functionality on older browsers that do not natively support it) based on the browser matrix you want to support
  • @babel/preset-react
    — this is going to compile the React code into ES5 code
  • babel-loader
    — this is a Webpack helper that transforms your JavaScript dependencies with Babel (i.e. will transform the import statements into require ones)

Since you are probably going to need to add some styles to your project (I know that I need them), we are going to add a loader that will let us import and use CSS files and SCSS files.

npm install --save-dev style-loader css-loader sass-loader node-sass
  • style-loader
    — this will add to the DOM the styles (will inject a <style> tag inside the HTML file)
  • css-loader
    — will let us import CSS files into our project
  • sass-loader
    — will let us import SCSS files into our project
  • node-sass
    — will compile the SCSS files into normal CSS files

We are going to create a new SCSS file and add it to our folders.

  1. Linux/MacOS command
touch src/index.scss
  1. Windows command
echo "" > src/index.scss

And also add some nice styles to it.

body {  div#root{    background-color: #222;    color: #8EE4AF;  }}

And change our index.js by adding an import for the SCSS file.

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

// this line is new// we now have some nice styles on our react appimport "index.scss";

let HelloWorld = () => {  return <h1>Hello there World!</h1>}

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

Don’t forget to delete the carets (^) from package.json.

This is how your package.json should look like:

{  "name": "react-webpack-babel-tutorial",  "version": "1.0.0",  "description": "This is a Tutorial to showcase the usage of React with Webpack and Babel",  "main": "index.js",  "scripts": {    "test": "echo \"Error: no test specified\" && exit 1",    "webpack": "webpack",    "start": "webpack-dev-server --open"  },  "repository": {    "type": "git",    "url": "git+https://github.com/creativetimofficial/react-webpack-babel-tutorial.git"  },  "keywords": [    "react",    "webpack",    "babel",    "creative-tim",    "material-design"  ],  "author": "Creative Tim &lt;hello@creative-tim.com> (https://www.creative-tim.com/)",  "license": "MIT",  "bugs": {    "url": "https://github.com/creativetimofficial/react-webpack-babel-tutorial/issues"  },  "homepage": "https://github.com/creativetimofficial/react-webpack-babel-tutorial#readme",  "devDependencies": {    "@babel/core": "7.0.1",    "@babel/node": "7.0.0",    "@babel/preset-env": "7.0.0",    "@babel/preset-react": "7.0.0",    "babel-loader": "8.0.2",    "css-loader": "1.0.0",    "html-webpack-plugin": "3.2.0",    "node-sass": "4.9.3",    "path": "0.12.7",    "sass-loader": "7.1.0",    "style-loader": "0.23.0",    "webpack": "4.19.0",    "webpack-cli": "3.1.0",    "webpack-dev-server": "3.1.8"  },  "dependencies": {    "react": "16.5.1",    "react-dom": "16.5.1"  }}

If we run any of the above commands again, the error will still persist. We haven’t yet told Webpack that it should use Babel and the style loaders to compile our React and SCSS code.

Next thing to do is add a configuration file for Babel. For this we need to create a file named .babelrc in which we will configure Babel.

I’ve heard that you can add the configuration for Babel directly in the webpack.config.js file. For this, you can take a look at the official babel-loader docs. As far as I am concerned, I think it’s best to have the Babel config in its own file. That way you do not overcrowd your Webpack config.

So, let’s run in the command line the following:

  1. Linux/MacOS command
touch .babelrc
  1. Windows command
echo "" > .babelrc

And add the following code inside .babelrc so that babel-loader will know what to use to compile the code:

{  "presets": [    "@babel/env",    "@babel/react"  ]}

After these steps, we will need to add something to our project so we can import all sorts of files such as images. We will also need to add a plugin that will let us work with classes and much more. Let us add class properties in our classes. Basically, it will let us work with Object Oriented Programming — nice.

npm install --save-dev file-loader @babel/plugin-proposal-class-properties

Now that we have done this, we need to make some changes inside webpack.config.js so that Webpack will now use Babel. We’ll also configure Webpack to listen for style files and we are going to change the require statements to import ones.

So this being said, let’s change our webpack.config.js to the following (I’ve also added some comments, maybe they will help you):

// old// const path = require('path');// const HtmlWebpackPlugin = require('html-webpack-plugin');// newimport path from 'path';import HtmlWebpackPlugin from 'html-webpack-plugin';module.exports = {  entry: path.join(__dirname,'src','index.js'),  output: {    path: path.join(__dirname,'build'),    filename: 'index.bundle.js'  },  mode: process.env.NODE_ENV || 'development',  resolve: {    modules: [path.resolve(__dirname, 'src'), 'node_modules']  },  devServer: {    contentBase: path.join(__dirname,'src')  },  module: {    rules: [      {        // this is so that we can compile any React,        // ES6 and above into normal ES5 syntax        test: /\.(js|jsx)$/,        // we do not want anything from node_modules to be compiled        exclude: /node_modules/,        use: ['babel-loader']      },      {        test: /\.(css|scss)$/,        use: [          "style-loader", // creates style nodes from JS strings          "css-loader", // translates CSS into CommonJS          "sass-loader" // compiles Sass to CSS, using Node Sass by default        ]      },      {        test: /\.(jpg|jpeg|png|gif|mp3|svg)$/,        loaders: ['file-loader']      }    ]  },  plugins: [    new HtmlWebpackPlugin({      template: path.join(__dirname,'src','index.html')    })  ]};

There’s one more change we need to do to the package.json file. We need to tell our scripts that inside the config files of Webpack, we use import instead of require statements. Else it will give us an error that it doesn’t know what import stands for.

{  "name": "react-webpack-babel-tutorial",  "version": "1.0.0",  "description": "This is a Tutorial to showcase the usage of React with Webpack and Babel",  "main": "index.js",  "scripts": {    "test": "echo \"Error: no test specified\" && exit 1",    "webpack": "babel-node ./node_modules/webpack/bin/webpack",    "start": "babel-node ./node_modules/webpack-dev-server/bin/webpack-dev-server --open"  },  "repository": {    "type": "git",    "url": "git+https://github.com/creativetimofficial/react-webpack-babel-tutorial.git"  },  "keywords": [    "react",    "webpack",    "babel",    "creative-tim",    "material-design"  ],  "author": "Creative Tim <hello@creative-tim.com> (https://www.creative-tim.com/)",  "license": "MIT",  "bugs": {    "url": "https://github.com/creativetimofficial/react-webpack-babel-tutorial/issues"  },  "homepage": "https://github.com/creativetimofficial/react-webpack-babel-tutorial#readme",  "devDependencies": {    "@babel/core": "7.0.1",    "@babel/node": "7.0.0",    "@babel/plugin-proposal-class-properties": "7.0.0",    "@babel/preset-env": "7.0.0",    "@babel/preset-react": "7.0.0",    "babel-loader": "8.0.2",    "css-loader": "1.0.0",    "file-loader": "2.0.0",    "html-webpack-plugin": "3.2.0",    "node-sass": "4.9.3",    "path": "0.12.7",    "sass-loader": "7.1.0",    "style-loader": "0.23.0",    "webpack": "4.19.0",    "webpack-cli": "3.1.0",    "webpack-dev-server": "3.1.8"  },  "dependencies": {    "react": "16.5.1",    "react-dom": "16.5.1"  }}

Another thing that we will have to still add is the @babel/plugin-proposal-class-properties to the .babelrc file. Babel will know how to deal with class properties.

{  "presets": [    "@babel/env",    "@babel/react"  ],  "plugins": [    "@babel/plugin-proposal-class-properties"  ]}

Now we are done. We can run either one of the above commands and it should not give us any errors. Let’s see them in action.

npm run webpack

Image npm run webpack with no errors

And now let’s see the main script of our app.

npm start

Image

Image npm start output

Add Material Design to our new React with Webpack and Babel project

As I’ve told you at the beginning of this post, we are not going to create from scratch styles for Material Design. That would require a lot of work. We don’t have time for that.

Instead, we are going to add a nice product that implements Google’s Material Design with some minor touches from the Creative Tim staff. We are going to add Material Dashboard React to it.

Image

First things first, you need to get the product. Here are a few ways of getting the product:

  • Clone the repo inside another folder:
git clone https://github.com/creativetimofficial/material-dashboard-react.git

Ok, so now we have both projects — Material Dashboard React and our newly created one with Webpack and Babel — with React.

Image material-dashboard-react and react-webpack-babel-tutorial

Now, we can’t simply copy the src folder from Material Dashboard React into our new project. That will give us a lot of errors. Such as errors for missing dependencies, module not found, you get the point, a lot of errors.

So, I suggest that we start with adding the dependencies from Material Dashboard React’s package.json to our package.json. We do not need all the dependencies from Material Dashboard React’s packages, since we have built our own server using Webpack. We have added other style loaders beyond what the product has.

So this being said, we need the following:

npm install --save @material-ui/core@3.1.0 @material-ui/icons@3.0.1 @types/googlemaps@3.30.11 @types/markerclustererplus@2.1.33 chartist@0.10.1 classnames@2.2.6 perfect-scrollbar@1.4.0 react-chartist@0.13.1 react-google-maps@9.4.5 react-router-dom@4.3.1 react-swipeable-views@0.12.15

We are not going through all of them. They can be found on npmjs.com with all the details and their own documentation.

Once again, we go inside the package.json file and delete the carets (^) from the packages that we just installed.

Ok, we are almost done. We are going to copy all the contents of the src folder from Material Dashboard React inside our project’s src folder and override the index.js file. But keep it in the index.html file.

Image

Image Folder structure before and after adding the Material Dashboard React src folder

Now we need to add some styles and fonts cdns inside our index.html.

<!DOCTYPE html><html lang="en">  <head>    <meta charset="utf-8">    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">    <meta name="theme-color" content="#000000">    <link rel="stylesheet" href="//cdn.jsdelivr.net/chartist.js/latest/chartist.min.css">    <script src="//cdn.jsdelivr.net/chartist.js/latest/chartist.min.js"></script>    <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700|Material+Icons">    <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">    <title>React Tutorial</title>  </head>  <body>    <noscript>      You need to enable JavaScript to run this app.    </noscript>    <div id="root"></div>    <!--      This HTML file is a template.      If you open it directly in the browser, you will see an empty page.      You can add webfonts, meta tags, or analytics to this file.      The build step will place the bundled scripts into the <body> tag.    -->  </body></html>

And we are almost there. We still have a small problem. When we refresh the page, we have an error Cannot GET /dashboard. If we navigate to another page we will get, for example, Cannot GET /user and so on. So basically, our routes do not work. We need to make some changes inside either src/index.js or inside our webpack.config.js.

I will choose the first option since it is pretty straightforward and easy to understand.

We navigate inside the new index.js and we change the history type. We put createHashHistory() instead of createBrowserHistory().

This will allow us to refresh the page without any other errors. Now we are done.

import React from "react";import ReactDOM from "react-dom";import { createHashHistory } from "history";import { Router, Route, Switch } from "react-router-dom";import "assets/css/material-dashboard-react.css?v=1.5.0";import indexRoutes from "routes/index.jsx";const hist = createHashHistory();ReactDOM.render(  <Router history={hist}>    <Switch>      {indexRoutes.map((prop, key) => {        return <Route path={prop.path} component={prop.component} key={key} />;      })}    </Switch>  </Router>,  document.getElementById("root"));

I really hope you’ve liked this tutorial and I am very keen on hearing your thoughts about it. Just give this thread a comment and I’ll be more than happy to reply.

Special thanks should also go to Linh Nguyen My for her tutorial which has given me some much needed understanding on Webpack.

Useful links:

Find me on:

]]> <![CDATA[ How to setup TinyMCE in your Rails app using Webpack ]]> https://www.freecodecamp.org/news/how-to-setup-tinymce-in-your-rails-app-using-webpack-edf030915332/ 66c354b1c45f383e42e907ae Wed, 19 Sep 2018 07:08:22 +0000 By Joanna Gaudyn

The popularity of using Webpack to deal with your assets in Rails is steadily increasing. Getting started is really straightforward. If you are starting a new app, you simply run rails new my_app --webpack and Rails takes care of the rest.

Thanks to the webpacker gem, adding Webpack to your existing application is also pretty uncomplicated. You add the gem to your Gemfile, bundle, and finally install webpacker:

gem 'webpacker', '~> 3.5'bundlebundle exec rails webpacker:install

This is pretty sweet. Now all you need to do is link your JavaScript pack and the CSS imported in it into the head of your application.html.haml:

<%= javascript_pack_tag 'application' %> <!-- js from app/javascript/packs/application.js -->

<%= stylesheet_pack_tag 'application' %> <!-- CSS imported via Wbpack -->

Once this is done, you are ready to write your modern JavaScript code and make use of all the great libraries out there.

What is tinyMCE?

TinyMCE is a rich text editor in the cloud. To put it simply, it’s like Word that can be implemented into your app.

The project I am working on uses it to let admins edit the content of the front page. Thanks to TinyMCE, it isn’t necessary to build a separate admin interface for that purpose. But the editor’s usage can be much more versatile. Think, for example, of what Wordpress or Evernote allows you to do thanks to their build in tools.

Image Example use of TinyMCE. The power is in the user’s hands now.

Usage via CDN

We originally implemented the editor via CDN (e.g. linking the script in the head of our application.html.haml) like this:

!!!%html  %head    %meta ... <!-- some meta content -->    %title ... <!-- MyApp -->    = csrf_meta_tags

    %script{src: 'https://cloud.tinymce.com/stable/tinymce.min.js?apiKey=gexncjni90zx3qf0m5rr7kl8l40wd5yuly2xjza0g3kwrljt'}    = stylesheet_link_tag 'application', media: 'all'    = javascript_include_tag 'application'  %body    <!-- the usual body stuff -->

This required adding a file with our customized function in app/assets/javascript/tinyMce.js. Note that we are also using jQuery.

$( document ).on('turbolinks:load', function() {

    tinyMCE.init({         selector: 'textarea.tinymce',             // some other settings, like height, language,         // order of buttons on your toolbar etc.             plugins: [            'table', 'lists' // whatever plugins you want to add        ]    });});

In addition to that, we had to include a translation file (which is not necessary if you’re using English in your app). For everything to display correctly in production, you’ll also need to get a free Tiny Cloud API key .

Webpack and tinyMCE

Everything was working great for a couple of months, but we decided that it was time for the transition towards Webpack.

Webpack is supposed to make your life easier and, coupled with yarn, lets you focus on the important stuff. Say you want to use package A. It so happens, that package A relies on packages B and C. And package B depends on D, E and F. Rather than spending hours figuring out what the dependencies are and installing them all individually, what you want is to say yarn add package-A, and have it figured out for you. And this is almost the case.

This transition when it came to tinyMCE was way more painful than it should have been. And that’s why I decided to write this post. I hope it saves someone some time and frustration.

If you previously had tinyMCE implemented via CDN, you’d like to get rid of some stuff, to start clean. Remove the script link from application.html.haml. Then comment out the content of the tinyMce.js file (and the language file if you’re using one). I also decided to get rid of the jQuery dependency (in our case it meant removing gem 'jquery-rails' from the Gemfile, and in the app/assets/javascripts/application.js removing //= require jquery and replacing //= require jquery_ujs with //= require rails-ujs).

Note: Proceed with caution if you have more external libraries in your project that rely on jQuery (e.g. Bootstrap or Select2). Ultimately your goal would probably be to move all of them to Webpack, but the bigger the project, the more complex that task could be, so just bear it in mind. Nothing stops you from keeping your traditional implementation parallel with the Webpack one. In that case I would still recommend commenting it out for the time of tinyMCE implementation.

All these steps will ensure that things we’ll be implementing from now on work, and the old implementation doesn’t function as a fallback.

Step 1. If you want to use jQuery via webpack

Adding jQuery through Webpack is as simple as running yarn add jquery and adding the following code to the config/webpack/environment.js:

const { environment } = require('@rails/webpacker')const webpack = require('webpack')environment.plugins.prepend('Provide',  new webpack.ProvidePlugin({    $: 'jquery',    jQuery: 'jquery'  }))module.exports = environment

Step 2. Get the tinyMCE package

That is also pretty straightforward: run yarn add tinymce.

Then create a new file where we’ll place our function. I ended up with app/javascript/vendor/tinyMce.js with the following content:

import tinymce from 'tinymce/tinymce';import 'tinymce/themes/modern/theme';import 'tinymce/plugins/table';import 'tinymce/plugins/lists';

function tinyMce() {    tinymce.init({        selector: 'textarea.tinymce',

        // some other settings, like height, language,         // order of buttons on your toolbar etc.

        plugins: [            'table', 'lists'        ]    });}

// if you're using a language file, you can place its content here

export { tinyMce };

Step 3. Import everything to the application.js

We can import our function like so:

import { tinyMce } from "../vendor/tinyMce";

and then call it:

document.addEventListener(“turbolinks:load”, function () {    tinyMce(); });

As you can see, we also replaced the jQuery code with ES6.

Step 4. Get the tinyMCE skin to work

If you run your webpack-dev-server and rails s you might be surprised to see that your text editor is not there. One look in the console and you’ll see the following error:

Image

This is because tinyMCE will not work without a skin, and pulling it in through Webpack requires its explicit import. We can do this by including this line in our tinyMce.js file, right after the other import statements. The path is relative to the node_modules folder:

import ‘tinymce/skins/lightgray/skin.min.css’;

At this point you should have your editor working.

But… if you look into the console, you might be disappointed to see that you are still getting 2 errors:

Image

Don’t despair! There is an easy fix. Just add skin: false to your function tinyMce() config and it should do the trick. This will prevent the default files from loading.

Congrats! You just got your tinyMCE up and running!

]]> <![CDATA[ Learn Webpack by example: simple code-splitting in a vanilla JavaScript app ]]> https://www.freecodecamp.org/news/learn-webpack-by-example-simple-code-splitting-in-a-vanilla-javascript-app-b366798336a4/ 66c359edd372f14b49bdcbe5 Mon, 10 Sep 2018 19:00:23 +0000 By Kalalau Cantrell

Using webpack 4 and dynamic imports

Image A tasty split

This article is part of an episodic guide for learning Webpack through various examples. If you need a refresher on what loaders and plugins are as far as Webpack goes, or what a basic webpack.config.js file looks like, check out this article I wrote that focuses on those basics.

If you are like I was, you have heard the term code-splitting before and have read some about it. But perhaps you kept running into posts about how to do it with this or that framework, rather than explanations of what is it for, and a basic example showing that purpose.

Although I highly value frameworks and the speed and structure they bring to coding, especially within teams, I also value understanding programming concepts as deeply as is practically possible.

This often means that if I’m trying to learn a new concept, I will try to decompose that concept into smaller sub-concepts and then study each in isolation before integrating them all together.

To use a non-programming example, if wanted to learn how to longboard, I’d want to focus heavily on just keeping my balance while standing on the longboard before I worry about going fast, doing tricks, or customizing my longboard setup.

So, to learn about code-splitting, I decided that I wanted to make as small and easy of an app as possible, which for me meant no frameworks and nothing fancy.

App overview

I want to share the little app that I made to help me explore code-splitting with Webpack. My hope is that it may help you better understand the topic as well. All we’re going to do is make the single page app depicted in the below gif.

Image A tasty route

If you want to follow along in your code editor, check out the code in the code-split branch of this repo. Once you install the packages, npm start will run a development server for you if you want to see the code-splitting in action.

Our app has two routes — a home route, which the user starts off on, and a tasty route. The view for the home route is very basic — just a header and a link to the tasty route.

The view for the tasty route, however, has much more going on. It features a delightful donut animation made with SVG and all the markup and CSS that goes along with that kind of thing. That is a lot of code compared to our home route. P.S. thanks Ben Visser for creating the animation.

Does it make sense to have the user download all the code for this app right away, including the code for the tasty route and its animation? Only if you were interested in causing slow initial load times and frustration, not to mention fear of missing out on what could have happened if the user stuck around for your app to load ;). So, let’s figure out how to code-split this thing.

First, however, is a high-level overview of the code behind the app. The app is written in vanilla JS. I only used one external library, [navigo](https://www.npmjs.com/package/navigo), to handle our client-side routing. Let’s look at the index.js file:

And here’s what the App module does:

And here’s an example of a UI component, our Home component:

No code-splitting

Without code-splitting, you would be sending your user one big bundle of code when they initially load your app. Let’s establish a baseline by looking at the size of our bundle here with no code-splitting.

You can see in the image below that the size of our bundle is 22.8K. Although that’s not very big compared to real apps in the world, let’s pretend it is for the sake of learning.

Image

Code-splitting with dynamic imports

Now let’s bring in the code-splitting! Remember, what we want to do is keep the user from having to download the code needed to render the tasty route until it is needed.

To accomplish this, we our going to use a feature that is coming to JavaScript called dynamic imports. Even though the feature hasn’t landed in the ECMAScript spec yet, Webpack and Babel allow us to use it now.

A dynamic import allows us to asynchronously fetch a module. It returns a promise. Within the promise callback, we can specify what to do with the module once it’s loaded. The syntax for a dynamic import looks like this:

import('./path/to/module')

When Webpack sees a dynamic import like this, it does not bundle up the imported module into the current bundle. Instead, it splits the bundle into two smaller chunks.

The current chunk may be synchronously loaded (like our initial page load), but the module that is imported by our dynamic import is asynchronously loaded. In our case, the module for the tasty route is loaded when the user vists that route.

In order to access the dynamic import feature, we’ll need to npm install a few Babel packages into our build process: babel-core, babel-loader and babel-plugin-syntax-dynamic-import are definitely needed.

Depending on the browser you’re using, you may not need babel-preset-env (i.e. the current version of Chrome supports all the other JavaScript syntax we’re using) but let’s get it anyway just for good measure.

Then, we configure Webpack for Babel:

So finally, we can write our dynamic import:

Here’s what this code says to do: when the tasty route is triggered, first fetch the Tasty component. Then, once it finishes loading, render it to the page.

Let’s see what this does for us. In the image below, you can see that the initial page load now downloads a bundle that’s 10.8K instead of 22.8K — much better! Then, when the user clicks to go to the tasty route, another bundle chunk of 13.6K is downloaded.

Image

Webpack automatically names these chunks — if you want control over that, check out this section of the webpack docs.

UX improvements

It’s great that we’ve saved the user from having to wait extra time for the page to initially load. But, can you guess what would happen if the user was on a super slow connection and tried to load the tasty route?

With the way we currently have things setup, the page would just hang there until the Tasty module fully loaded. These few moments of hanging might leave the user wondering if our app was even working.

Let’s improve this experience by giving the user some signal that our app is doing something while they wait:

Now, our app will show a loading spinner while the Tasty component loads. While this may increase the size of our initial bundle some, it gives the user an indication that something is going on while they wait.

This trade off exchanges some performance for a better user experience — finding that balance is what it’s all about!

Image

Conclusion and further reading

I hope this example served as a simple portrayal of the benefit of code-splitting as well as how to use a tool like Webpack to help you do it.

I also hope it showed that code-splitting is not a technique that’s useful just for certain frameworks. In fact, vanilla JS apps can make use of code-splitting, and even apps that are mostly server-rendered but have interactive widgets embedded here and there can make use of the technique.

If you want to dive deeper into some granular code-splitting that webpack lets you do, look into the [optimization.splitChunks](https://webpack.js.org/plugins/split-chunks-plugin/) plugin that comes with webpack 4.

Please clap if this helped you learn something, comment below with any questions, and feel free to say hi to me on Twitter.

]]> <![CDATA[ How to compile Sass files in Visual Studio and Webpack ]]> https://www.freecodecamp.org/news/how-to-compile-sass-files-in-visual-studio-and-webpack-6e45cdc1c14c/ 66d45e3c9208fb118cc6cf8f Fri, 07 Sep 2018 16:38:25 +0000 By Esau Silva

Sass is a very popular CSS pre-processor. The intent of this tutorial is to show you how to compile Sass files within Visual Studio using Webpack. Our discussion will include minification and autoprefixing for production.

Image Visual Studio meets Sass

Sure, there are some plug-ins in the Visual Studio Marketplace, and it can be nice to just install a plug-in and forget about configuration. But what happens if the plug-in is not supported anymore and stops working with newer Visual Studio versions? Well, too bad. This is the case with one of the most popular compiler plug-ins on the market.

By configuring the compilation yourself, you will have total control over the output. Also, vendor prefixes will be added automatically to your CSS rules. How cool is that?

Prerequisites

You will need to have Node installed, and you can grab it here. That’s it really. You’ll also need npm, but it will also be installed with Node.

Creating the Project

Note: We will be creating a .NET Core MVC app, but the same principles apply to any ASP.NET MVC app. You would just need to modify the Webpack configuration a little bit to output the CSS file to the Content directory.

Open Visual Studio and create a new ASP.NET Core Web Application, then select Web Application (Model-View-Controller). I’m naming my project netcore-sass-webpack.

Image Creating the project

Create a Styles folder within the root of the project. Inside it, create a Sass file and name it site.scss. Open this new Sass file and copy the following:

/* Please see documentation at https://docs.microsoft.com/aspnet/core/client-side/bundling-and-minification\ 
for details on configuring this project to bundle and minify static web assets. */
body {
    padding-top: 50px;
    padding-bottom: 20px;
    background: #D69655 url('../wwwroot/images/pattern.png') repeat;
}

/* Wrapping element */
/* Set some basic padding to keep content from hitting the edges */
.body-content {
    padding-left: 15px;
    padding-right: 15px;
}

/* Carousel */
.carousel-caption p {
    font-size: 20px;
    line-height: 1.4;
}

/* Make .svg files in the carousel display properly in older browsers */
.carousel-inner .item img[src$=".svg"] {
    width: 100%;
}

/* QR code generator */
#qrCode {
    margin: 15px;
}

/* Hide/rearrange for smaller screens */
@media screen and (max-width: 767px) {
    /* Hide captions */
    .carousel-caption {
        display: none;
    }
}

You will notice that this is the same CSS provided by Visual Studio when we created the project, with the exception of the background rule in the body tag. Now delete the provided CSS located under wwwroot/css (both files: site.css and site.min.css). Don’t worry, we will auto-generate these with Webpack.

Now, download pattern.png and place it under wwwroot/images.

Create an empty JavaScript file under the root of the application and name it webpack.config.js. We will take care of this later. You should end up with the following project structure:

Image Project Structure

Note: You don’t need to do the following two steps for every project, just once (unless you un-install and re-install Visual Studio).

You will need to provide Visual Studio with the Node installation path. Go back to your project and select Tools -> Options on the left pane Projects and Solutions -> Web Package Management and add the path to Node installation at the top of the list ( C:\Program Files\nodejs or C:\Program Files (x86)\nodejs, depending if you installed the x64 or x86 version).

Image Node path

Finally download NPM Task Runner and install it — but you will need to close Visual Studio first.

Webpack and NPM Dependencies

Open Command Prompt and navigate to the root of the project and install the needed dependencies:

cd netcore-sass-webpack\netcore-sass-webpack
npm init -y
npm i -D webpack webpack-cli node-sass postcss-loader postcss-preset-env sass-loader css-loader cssnano mini-css-extract-plugin cross-env file-loader

The first npm command initializes your package.json and the second installs your dependencies.

  • webpack, webpack-cli — Module bundler
  • node-sass — Bindings for Node to LibSass; provides support for Sass
  • postcss-loader, postcss-preset-env — PostCSS loader for Webpack to process autoprefixing and minification
  • sass-loader, css-loader — Webpack needs specific loaders to support Sass and CSS
  • cssnano — CSS minifier
  • mini-css-extract-plugin — Extracts the CSS to a separate file
  • cross-env — Provides support to Windows users for environment variables. We will use NODE_ENVenvironment variable
  • file-loader — Provides support for files (images) in our CSS rules

At this point you can re-open the project in Visual Studio. After the project finishes loading, open package.json and add the following scripts:

"scripts": {
    "dev": "webpack --watch",
    "build": "cross-env NODE_ENV=production webpack"
  },
  • dev — We will bind this script whenever the project opens, and Webpack will continually watch for changes to the source Sass files, compile them, and output the separate CSS file
  • build — We will bind this script before each project build and will produce the production CSS file, including minification and autoprefixing

Note: The NPM scripts will run automatically using the Task Runner window. More on that later.

It is time to work on our Webpack configuration. Open webpack.config.js and copy the following:

const path = require("path");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const postcssPresetEnv = require("postcss-preset-env");
// We are getting 'process.env.NODE_ENV' from the NPM scripts
// Remember the 'dev' script?
const devMode = process.env.NODE_ENV !== "production";
module.exports = {
  // Tells Webpack which built-in optimizations to use
  // If you leave this out, Webpack will default to 'production'
  mode: devMode ? "development" : "production",
// Webpack needs to know where to start the bundling process,
  // so we define the Sass file under './Styles' directory
  entry: ["./Styles/site.scss"],
// This is where we define the path where Webpack will place
  // a bundled JS file. Webpack needs to produce this file,
  // but for our purposes you can ignore it
  output: {
    path: path.resolve(__dirname, "wwwroot"),
// Specify the base path for all the styles within your
    // application. This is relative to the output path, so in
    // our case it will be './wwwroot/css'
    publicPath: "/css",
// The name of the output bundle. Path is also relative
    // to the output path, so './wwwroot/js'
    filename: "js/sass.js"
  },
  module: {
    // Array of rules that tells Webpack how the modules (output)
    // will be created
    rules: [
      {
        // Look for Sass files and process them according to the
        // rules specified in the different loaders
        test: /\.(sa|sc)ss$/,
// Use the following loaders from right-to-left, so it will
        // use sass-loader first and ending with MiniCssExtractPlugin
        use: [
          {
            // Extracts the CSS into a separate file and uses the
            // defined configurations in the 'plugins' section
            loader: MiniCssExtractPlugin.loader
          },
          {
            // Interprets CSS
            loader: "css-loader",
            options: {
              importLoaders: 2
            }
          },
          {
            // Use PostCSS to minify and autoprefix with vendor rules
            // for older browser compatibility
            loader: "postcss-loader",
            options: {
              ident: "postcss",
// We instruct PostCSS to autoprefix and minimize our
              // CSS when in production mode, otherwise don't do
              // anything.
              plugins: devMode
                ? () => []
                : () => [
                    postcssPresetEnv({
                      // Compile our CSS code to support browsers
                      // that are used in more than 1% of the
                      // global market browser share. You can modify
                      // the target browsers according to your needs
                      // by using supported queries.
                      // https://github.com/browserslist/browserslist#queries
                      browsers: [">1%"]
                    }),
                    require("cssnano")()
                  ]
            }
          },
          {
            // Adds support for Sass files, if using Less, then
            // use the less-loader
            loader: "sass-loader"
          }
        ]
      },
      {
        // Adds support to load images in your CSS rules. It looks for
        // .png, .jpg, .jpeg and .gif
        test: /\.(png|jpe?g|gif)$/,
        use: [
          {
            loader: "file-loader",
            options: {
              // The image will be named with the original name and
              // extension
              name: "[name].[ext]",
// Indicates where the images are stored and will use
              // this path when generating the CSS files.
              // Example, in site.scss I have
              // url('../wwwroot/images/pattern.png') and when generating
              // the CSS file, file-loader will output as
              // url(../images/pattern.png), which is relative
              // to '/css/site.css'
              publicPath: "../images",
// When this option is 'true', the loader will emit the
              // image to output.path
              emitFile: false
            }
          }
        ]
      }
    ]
  },
  plugins: [
    // Configuration options for MiniCssExtractPlugin. Here I'm only
    // indicating what the CSS output file name should be and
    // the location
    new MiniCssExtractPlugin({
      filename: devMode ? "css/site.css" : "css/site.min.css"
    })
  ]
};

Refer to the comments in the code to understand the configuration. (More readable file here.)

Now we need to create some bindings in Task Runner Explorer. Navigate to View -> Other Windows -> Task Runner Explorer. The window will show at the bottom and you will see the scripts you created in package.json listed there under Custom. You will also see some tasks under Defaults, but you can just ignore them.

We need two bindings:

  • Right click build -> Bindings -> Before Build — Visual Studio will run this task before each build. Remember this npm script runs Webpack for production and will optimize the CSS file.
  • Right click dev -> Bindings -> Project Open — Visual Studio will run this task when you open the project. Remember this npm script runs Webpack in watch mode and will watch for any changes in your Sass files and output the processed CSS file.

Task Runner Explorer should look like this:

Image Task Runner Explorer

Note: For some reason, Visual Studio sometimes will fail to start the dev task upon opening the project. If that happens, just open the Task Explorer and run the task manually.

You can get the full code from the GitHub repository.

Final Thoughts

And that’s all there is too it. Since you already have Visual Studio open, none of the tasks are running. Go ahead and right click the dev task and select run. You will see the task loading and when it finishes you will see that a site.css file was created under wwwroot/css directory. Open site.scss, make a change and save it. Now open site.css, you will see your change reflected there. Cool!!

Run your project by pressing Ctrl + F5, you will see a site.min.css file created under wwwroot/css directory. This file was created when Task Runner ran the build script before it built the project.

The final site should look like this:

Image Final site

I know, I know, the background is very cheesey…but I needed an image to show the Webpack file-loader in action.

With this configuration, you can even add support to transpile modern JavaScript (ES6+) to ES5. Look into these: @babel/core, babel-loader, @babel/preset-env.

Thank you for reading, and I hope you enjoyed it. If you have any questions, suggestions, or corrections let me know in the comments below. Don’t forget to give this article a share, and you can follow me on Twitter, GitHub, Medium, LinkedIn.

You can also visit my personal blogging site.

Update 8/25/19: I have been building a prayer web app called "My Quiet Time - A Prayer Journal". If you would like to stay in the loop please sign up through the following link: http://b.link/mqt

The app will be released before the end of the year, I have big plans for this app. To see some mockup screenshots follow the following link: http://pc.cd/Lpy7

My DMs on Twitter are open if you have any questions regarding the app ?

]]>