Rescreve essa outra parte do artigo com as seguintes condições:

1. Reescreva em português.
2. Toda parte que utilizar uma palavra difícil ou se há uma parte difícil de entender, deixe ele mais claro e fácil de entender.
3. O artigo deve reescrito em forma de tutorial passo a passo.
4. Não elimine informações dadas no artigo.


"Introduction
In the previous lesson, we introduced ES6 modules (ESM) and npm. The introduction of ESM greatly mitigated some of the issues with managing individual script files and dependencies. However, downloading a large number of module files individually can reduce performance, especially as more third party files are imported.

Fortunately, more recent web technologies have greatly improved these aspects, but bundlers still provide us with a lot of power to process and optimize our code in various ways. This power, however, does come with the small cost of needing to configure a bundler. For now, our needs are few and simple, and we can look at the basic things one at a time.

Awareness of bundlers and basic experience with them is valuable. While in recent years, new build tools have come out that handle a lot of basic configuration for us, in the real world, you may not always get a chance to use these shiny new tools. It’s very reasonable to end up working with codebases that use tools that require more manual configuration. Even if you did get to work with tools that handle more things for you, it’s useful to understand what those tools are actually doing for you.

Lesson overview
This section contains a general overview of topics that you will learn in this lesson.

Explain the purpose of bundlers and how they work.
Configure Webpack to bundle JavaScript modules.
Configure Webpack to handle non-JavaScript files during bundling, including using HtmlWebpackPlugin.
Set up Webpack’s development server.
Bundling
In the previous lesson, we learned what an entry point is, what a dependency graph is, and how to add an entry point file to HTML as a module script. With bundling, the same concepts of entry points and dependency graphs apply: we provide the bundler with an entry point. It then builds a dependency graph from that file, combines all relevant files together, and then outputs a single file with all the necessary code included.

While it does this, we could also get it to do a whole bunch of other things, such as minifying our code, image optimizations, or even “tree shaking”. Most of these extra optimizations are out of the scope of this course; we will instead be focusing on basic bundling of JavaScript, and handling HTML, CSS, and images.

Webpack
Webpack is one of the most popular JavaScript bundlers, if not the most popular one, and has been for a long time. Let’s get started with bundling!

We’ll first need to make a new directory for our practice app, then create a package.json file in it for npm to record information about packages we use (like Webpack). Run the following in your terminal:

mkdir webpack-practice &&
cd webpack-practice &&
npm init -y
Once inside your new directory, we can go ahead and install Webpack, which involves two packages.

npm install --save-dev webpack webpack-cli
Note that we included the --save-dev flag (you can also use -D as a shortcut), which tells npm to record our two packages as development dependencies. We will only be using Webpack during development. The actual code that makes Webpack run will not be part of the code that the browser will run.

Also notice that when these finished installing, a node_modules directory and a package-lock.json got auto-generated. node_modules is where Webpack’s actual code (and a whole bunch of other stuff) lives, and package-lock.json is just another file npm uses to track package information.

src and dist
When dealing with Webpack (and often with any other bundler or build tool), we have two very important directories: src (short for “source”) and dist (short for “distribution”). We could technically call these directories whatever we want, but these names are conventions.

src is where we keep all of our website’s source code, essentially where all of our work will be done (with an exception being altering any configuration files in the root of the project). When we run Webpack to bundle our code, it will output the bundled files into the dist directory. The idea is that if someone were to fork or clone the project, they would not need the dist directory, as they’d just be able to run Webpack to build from src into their own dist. Similarly, to deploy our website, we would only need the dist code and nothing else. Keep that in mind! Work inside src, build into dist, then deploy from there!

Bundling JavaScript
Import file extensions
Normally, with ESM, we need to specify file extensions when we import from other files (e.g. "./greeting.js"). With Webpack and many other bundlers, some file extensions like .js are optional, as Webpack will automatically check extensionless file paths for .js files by default (e.g. "./greeting").

This is a feature of Webpack, not ESM.

In this lesson, examples with imports will always include the file extension where appropriate to be explicit.

Now that we’ve installed Webpack in our project directory, let’s create a src directory with two JavaScript files inside it: index.js and greeting.js.

mkdir src && touch src/index.js src/greeting.js
Inside our two JavaScript files, we’ll have the following:

// index.js
import { greeting } from "./greeting.js";

console.log(greeting);
// greeting.js
export const greeting = "Hello, Odinite!";
Great, now we have an index.js that imports from, and so depends on, greeting.js. In order to bundle this, we’ll also want a Webpack configuration file, which will contain all the details we need for bundling, such as the entry point, the output destination, and anything like plugins and loaders (which we will cover shortly).

Back in your project root (so outside of src), create a webpack.config.js file that contains the following:

// webpack.config.js
const path = require("path");

module.exports = {
  mode: "development",
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist"),
    clean: true,
  },
};
Yes, you may have noticed this file uses CommonJS (CJS) syntax instead of ESM. That’s because this file (and Webpack itself) runs in NodeJS and not the browser. By default, NodeJS uses CJS syntax, and the configuration file also contains some CJS-specific things. We need not worry about this - this is just stuff we need for Webpack to do its thing.

You’ll notice the exported object contains a few key sections:

mode: For now, we will just leave this in development mode, as it will be more useful to us. We will revisit this and production mode in a later lesson.
entry: A file path from the config file to whichever file is our entry point, which in this case is src/index.js.
output: An object containing information about the output bundle.
filename: The name of the output bundle - it can be anything you want.
path: The path to the output directory, in this case, dist. If this directory doesn’t already exist when we run Webpack, it will automatically create it for us as well. Don’t worry too much about why we have the path.resolve part - this is just the way Webpack recommends we specify the output directory.
clean: If we include this option and set it to true, then each time we run Webpack to bundle, it will empty the output directory first before bundling the files into it. This helps us keep dist clean, so it only contains the files produced by the most recent bundling.
With these files all in place, let’s run Webpack and see what happens!

npx webpack
You should see that Webpack has created a dist directory for us containing a main.js file! Inside this file is…a lot of stuff… Don’t worry, most of this stuff is just for development tools we will use later. If you go ahead and run this file with node dist/main.js, you should see Hello, Odinite! logged in the terminal.

Congratulations! You’ve just made your first bundle with Webpack!"