In this lecture, we are going to configure Webpack.
This process is going to involve a couple of steps.
First, let's take a moment to understand what we're trying to accomplish.
We need Webpack to process HTML JavaScript and rust.
Compiling rust with web pack will be another lecture.
We're going to focus solely on H.G, HTML and JavaScript.
The stages of bundling code look like this.
First, we have our project code.
Our code is given to web pack for processing.
After a few moments, Web Pack will spit out a bundle.
Web Pack needs some information about our project before it can begin the process of bundling our code.
First, it needs the entry point.
The entry point can be considered the root JavaScript file.
The root file is responsible for importing files.
Second, it needs the output for the bundle.
We can tell Web Pack where to upload our project's bundle if we configure these settings.
Web Pack will take care of the rest.
To get started, we need to create a configuration file by default, Web pack will search for a file
called web packed config dot J.S. in the root directory of our project.
Let's take a moment to create this file.
Inside this file, we're going to export an object through the module exports property.
The object we're exporting will contain the configuration settings for a Web pack, as mentioned before,
we should tell Web Pack where to find our files in the resource section of this lecture.
I provide a zip file with some starter files before continuing.
Download it.
In a moment, we're going to need it.
Typically, JavaScript applications are written in a directory called source.
However, Rust has claimed this directory.
We should keep our rust and JavaScript code bases separate.
Luckily, we're not going to heavily write JavaScript inside our project, create a folder called public.
The public folder will house our HTML and JavaScript files.
Let's drag and drop the files from the zip file to this directory.
I'm going to quickly do that.
I am providing a total of two files.
Let's explore them.
The first file is the index, not a simple file.
There's not much to say about this file.
There's a lot of code.
But you can mostly ignore it at the top.
I'm importing tailwind and a font from Google.
Both files are served from external sources.
They're going to make our app look cool.
The most important tags in this file can be found near the bottom of the document.
I have added emailed comments above the elements there, the input and image tags in a future lecture.
We are going to listen to an event on the input element for file uploads.
The image tag will be updated when the file has been processed.
I've taken the time to assign IDs to both elements.
We will select them from the JavaScript file.
Speaking of JavaScript, let's open the main a.j.'s file in the public folder.
There isn't a lot happening in this file.
We're keeping it simple by logging a message.
As you can see, we're developing a small app.
Let's begin loading these files switched back to the web pack configuration file inside the object.
We're going to add a property called entry.
The entry option allows us to specify a path to a file in our case, we want to point to the GPS file,
set this option to the following public slash.
Yes.
We're using a relative path.
Make sure to add the dot forward slash characters.
Next, we can begin specifying the output.
The output is where we can tell web pack where to store the bundle.
Add a new property called output with an initial value of an object.
The configuration for the output is going to be more complex than configuring the entry web pack with
like two pieces of information, which are the name of the directory and file, we can set the directory
by adding the path property.
The value for this property must be a full system path.
We can't use a relative path.
No, Jess has a package for generating for system paths at the top of the file import the path package
with the required function.
Next, we're going to set the path property to the path dot resolve function.
This function accepts a list of paths to a pen together.
We're going to pass in a constant called underscore underscore directory name and a directory called
distribution.
The directory name constant is defined by node.
This constant returns the path of the folder to where the current JavaScript file resides.
Afterward, we're telling web PAC to place our files in a directory called distribution.
It's common practice to use this name.
You're more than free to change the directory name afterward.
Let's add an option called file name.
This option is for configuring the name of the file produced by a web pack.
Feel free to use whatever name you would like.
I'm going to call our file index Donges.
We're almost finished.
We've bundled the JavaScript file, but not the HTML file by default, Web Pack does not provide full
support for HTML files.
Luckily, there's a plugin for helping web pack create a HTML files inside the command line.
Run the following command and p.m. install minus d h html web pack plugin.
The package we've installed is a plug in for processing H.M. files with Web pack.
Let's give it a try.
Back in the configuration file import the Gmail Web Pack plug in with the required function.
A plugin extends the behavior of Web pack.
There are various plugins available, configuring them with web pack tends to be a similar process inside
the configuration object.
We can add an array called plugins.
Next, we can create a new instance of the female web pack, plug an object.
The new instance will configure the plugin with Web pack.
It's very hands off.
However, we should tell the plugin where it can find the HTML file.
By default, this plugin will generate a custom HTML file.
We can override this behavior by passing in an object with a property called templates.
The value for this property must be a relative path to the HTML file past and the following value public
slash indexed HTML.
With that final piece of the puzzle in place where a finished let's start the development server, open
the package doc JSON file.
We're going to outsource the commands to these scripts object.
Replace the current command with a new command called serve.
If this command gets executed, we'll run the following Command Web pack serve mode equals development.
The Webpack command is available through the Web Pack Seelye Package, the service of Command will tell
Web Pack to create a development server.
With this single command, we can avoid writing a custom server.
Lastly, we're setting the mode option to development web pack ships various modes with different optimization
settings.
Web Pack will optimize the bundle for development, which can be helpful for debugging.
Next, let's add another command called built.
The value for this command will be the following Web pack mode equals production.
We're using the Webpack command again, this time we're setting the mode to production.
The bundle will be optimized for deploying to production servers.
Our commands are ready.
Let's give our development server a test inside the command line.
Run the following command and 21:00 run serve.
After a couple of seconds, Web pack will generate a bundle during development mode, Web Pack will
watch our files for changes if we modify our files.
The bundle will get refreshed.
This is the power of web pack inside the command line.
A preview URL will be provided.
Let's open this URL in our browser.
Here's our app in all its glory.
Finally, we're ready to start processing images.
The first step is to start reading files uploaded by the user.
We'll begin this task in the following lecture.