- [Instructor] VC code supports ESLint with an extension,
and it can even fix code automatically.
The ESLint extension by Dirk Baumer
uses the ESLint library
installed in the current workspace folder.
Additionally, ESLint will report errors and warnings
within the IDE as you're writing code.
Another feature is that the extension
can automatically fix code when you save a file.
Let's get it installed.
Switch over to visual studio code.
Let's clean up our workspace a little bit
by closing out the ESLint ignore file,
then, over in the activity bar
on the left, click extensions.
We're going to search for D B A E U M E R,
and we're going to select ESLint.
When found, click the install button.
That's all we need for now.
We can close the extension configuration
and then go back to the Explorer.
Since this is the first time we're running the extension,
we're going to need to give it permission.
Right here, ESLint is disabled
since its execution has not been approved or denied yet.
Use the light bulb, we'll click on it,
show fixes ESLint manage library execution.
I don't want to allow everywhere
to remember this choice for all workspaces,
so I'll just click allow for this current workspace.
ESLint has added a few things to the editor.
In the bottom left of the sidebar,
there's a summary of the errors and warnings.
If I click on it, I will get a problem list.
In the editor itself, there are now underlines
with different colors for warnings and errors.
When I hover over an underlined portion such as for a VAR,
I see a description of the rule that is violated.
In this case, unexpected VAR use let or const instead.
If I hover over the yellow lines,
I see that I violated the empty line rule.
Now it's time to start cleaning things up.
How can we fix lint errors quickly?
ESLint does have the ability
to fix some of the errors it detects.
It's all or nothing though,
so it tempts to fix everything in a specified file.
The command line version does not selectively fixed lines,
so be careful when using it.
Individual lines can be selectively fixed
in the IDE however, like any powerful tool,
auto fixing can be useful in moderation.
The extension we're using does support fixing on save.
I usually avoid using this feature on an existing code base.
In my opinion, both changes should be intentional
not automatic.
Instead, it's better to manually execute the commands
that changes things.
Different organizations have different opinions
and philosophies around preserving history.
So do what's right for your group.
To automatically fix a file,
you'll need to open VS Codes, Command Palette
which is Control, Shift, and P.
You'll be prompted for the name of the command
which is ESLint fix all auto-fixable problems.
Let's clean up app.js.
Return to VS Code, make sure that app.js is selected,
then toggled the command palates
by using Control, Shift and P.
Start typing the command,
which is fix all auto.
And that should bring up fix all auto-fixable problems.
Press Enter and ESLint will attempt to clean things up.
The file immediately changed.
Most things are fixed, but some are not.
That's a lot better than it was, no more VARs either.
In the sidebar on the bottom, only four areas remain.
Clicking on the top error,
configuration is assigned to value but is never used.
We can safely delete this line.
There's two errors about the unexpected constant condition
and the empty block statement.
We can delete this if statement entirely.
One more error remains, next is defined but never used,
however, it's necessary for error handling
so we have to keep it.
For now, let's ignore it,
although the better solution would be to check
if the headers were already sent and call next.
So let's go to that error,
and we're going to navigate to the end of the line.
We're going to add a space and then add a comment,
we're going to use a special command to ESLint
to disable the line and specify the rule we're disabling
specifically no one used VARs.
So //eslint-disable-line nounusedvars.
Save the changes, and now all the errors are addressed.
Let's click on the close panel and close out app.js.
Let's update the Read Me to include linting information.
Clicking readme.md in the Explorer,
then after the editor config line under development add,
this project uses ESLint
to detect suspicious code in JavaScript files,
visit httpseslint.org for details.
Save the changes and finally close the file.
In this chapter,
we've been focusing on finding suspicious code with Linting.
We started with standardizing editor configurations
using the open source file format, EditorConfig,
and associated extensions.
Then we added EditorConfigs support
to both the project and to VS Code.
We compare the differences between JavaScript's linters
then installed the most flexible option ESLint
into the project.
We created an ESLint configuration
then extended an existing one.
To show all errors at once,
we linted the entire code base,
then selectively ignored a directory
and added a configuration override.
Finally, we cleaned code within VS Code using ESLint.
Now that we have ways of scanning the code
for syntax and style problems,
let's validate the correctness
of the application using unit testing.