Before we look at Image Optimization,
I want to set up ESLint in our project.
ESLint is a tool that can analyze our
code to find possible problems,
and Next.js provides some predefined rules
that can help us avoid issues in
our pages or other components.
Let's start by installing ESLint.
So I'll open the Terminal,
and we can add it to our "devDependencies"
by running "npm install --save-dev eslint"
and then we also want the "eslint-config-next"
package,
that contains the Next.js specific rules.
The dependencies have been installed.
Now, npm currently reports some "vulnerabilities".
Maybe they will have been resolved
by the time you watch this video,
but since I frequently get questions about this,
let me quickly explain something
about "npm audit".
Just because npm reports some "vulnerabilities"
it doesn't mean they're actually
a problem in your own project.
They're just "potential" vulnerabilities.
Now, I'm not saying you should just blindly
ignore the warnings of course,
what I am saying is that we should run "npm audit"
and look at the details.
In this case the "vulnerability"
is in a package called "semver".
And that library is used as a dependency
by 4 eslint packages.
That's why npm reports "5 vulnerabilities"
in total,
but in realityÂ it's just 1.
Anyway, what's more important is
what the actual problem is.
It says semver is "vulnerable to Regular
Expression Denial of Service",
and there's a link where to find more details.
Now, "Regular Expression Denial
of Service" means that
there is some code in the "semver" library
that uses a regular expression,
probably to parse version numbers,
since "semver" is short for "semantic versioning".
And if the string it's trying to parse is
deliberately written in a certain way
that can cause the regular expression
code to run very slowly.
So if you run that code in a server
that provides a user interface,
or an API, that allows users
to send the input string,
somebody could abuse it to make
your server very slow,
causing a so-called "Denial of Service".
Now, the point is: that's not how we're
using that library in our project.
We're not going to run it in
our server in production;
it's only used by "eslint",
that's a tool we only run in development,
to check our own code.
So, given the way we use that
dependency in our project
there is no reason to worry about
this potential vulnerability.
Anyway, let's go back to setting up ESLint.
We want to create a configuration
file called ".eslintrc.json".
This contains a JSON object
with the ESLint settings.
For Next.js we want to set it to extend
the "next/core-web-vitals" configuration.
This will enable all the Next.js
and related rules.
At this point we can open our "package.json" file
and add a script to run the "lint" checks
by executing "next lint".
If you initialize a project with "create-next-app"
it will set up these things automatically for you.
But this way we can run the checks in the terminal
by typing "npm run lint",
and this will analyze our code
and report any problems.
You can see that there are 3 warnings,
in 3 different pages.
The message is the same in every case:
it says "Using img could result in
slower LCP and higher bandwidth."
"Consider using Image from next/image
to automatically optimize images."
So, this rule is encouraging us to
use the Next.js Image component
rather than the standard HTML "img" tag,
because that way our images will be
smaller and should load faster.
Let's go and look at the code
mentioned in the warnings.
One of the files it reported was
the "ReviewsPage' for example.
Here we have a standard HTML "img" element.
We'll see how to use the Next.js Image
component instead in the next video.
But, before that, I suggest installing
the ESLint extension as well.
If we search the Visual Studio
Code extensions for "eslint",
there is an official one by Microsoft
and that's what we want to install.
This will check our code directly in the editor.
So, if we go and look at the same page again,
we should now see that
Visual Studio Code displays a warning
underneath the "img" element.
And if we move the mouse over the suspicious code
it will show the same ESLint
message we saw earlier.
But using the Visual Studio Code
extension is much easier
than having to run a separate
command in the terminal.
We'll see how to get rid of this
warning in the next video.