- [Sasha] Automating ESLint within a build process

makes it really easy to enforce styles

before deploying code.

But you can also use ESLint earlier

in your development process

to flag issues before you even commit them.

All the major code editors,

Visual Studio Code, Sublime Text and Atom,

as well as a lot of other IDEs support extensions

that check code against ESLint rules

while you're writing it

and flag issues right in the editor window.

I'm using Visual Studio Code.

To integrate ESLint, I can just add an extension.

So I'll open up extensions

and I'll search on ESLint.

And the first one that shows up

is the ESLint extension by Dirk Baeumer.

So it's always a good idea

to check the number of installs in the rating

and this one, after seven million installs,

it has about a four and a half star rating

and that's a great sign.

And in fact, I've used this one before and it is.

So I'll hit install.

And now it's enabled.

So from now on, whenever I open a JavaScript file

that's associated with a .eslintrc file,

the ESLint extension will lint the file

and flag any issues right in the editor window.

So let's test that out.

I'm going to go back to the explorer,

and I'm going to open up,

we'll close that up,

I'm going to open up my index.js file.

And I can see here that the console.log statement

has a yellow wavy line underneath it.

And if I hover over that,

I see the explanation that my ESLint rules call

for eliminating console statements.

Now, if you don't see that,

the settings for your extension may need

a little bit of adjustment.

For VS Code in particular,

you need to go into the preferences,

so I usually open up the control panel and

I can do Preferences: Open Settings JSON

to get to the JSON file,

and if you go to the wiki page for this video,

there's a Visual Studio Code configuration snippet

that you can just add to that JSON configuration.

And if that ESLint integration isn't working,

then adding this snippet to your JSON config may help.

But mine's working okay.

I'm not going to add that in.

So ESLint can flag a whole wide variety of errors.

And being reminded of those as you code

can be really helpful.

So I'm going to write some bad code

just to test things out.

And this is another thing I've included

in the wiki for this video.

So just this three-line for statement,

I'm going to copy and paste in here.

And immediately when I paste that in,

I see a lot of underlining,

and it's in red this time, not in yellow.

Also in the file list over here on the left

in the explorer, the file name is in red

and I see this number five.

And that indicates the number of issues this file has.

And also the containing folder has a red dot meaning

that it contains files that have issues.

So my for loop starts with a value of 10.

And it checks for a value greater than zero.

But it's incrementing after every loop.

And this is a logic error.

It means it's never going to get to zero,

it's never going to stop,

so I've created an infinite loop here.

And that can be tricky to catch

if you're just writing code

and trying to figure out why your code isn't working.

But the configuration I'm using flags this.

And so if I hover over it,

there's a pretty simple explanation

of what's going on here, the for direction is wrong.

And so if I change that greater than to a less than,

most of that red goes away.

I've fixed that logic error.

Now, there's still a bit more going on here.

So if I hover over that i++,

which has a red underscore,

there's an explanation about avoiding unary operators.

I like doing that in my code as well

because unary operators can have unexpected effects

based on order.

So I'll replace that ++ with a +=1.

Now, I still have a red underline.

And if I hover over it this time,

I see that my rules require spacing around this operation.

Again, this is a useful style

to make my code more readable.

So I'm going to add those spaces.

One before the plus, one after the minus.

And now all of those squiggles are gone.

I have another yellow squiggle

under my console.log statement.

And that flags another warning

about console statements,

and I'm okay with that for right now.

And then I have a squiggle under my closing curly brace.

And if I hover over that,

there's an explanation that my rules call

for an empty line at the end of a file,

which is a great practice.

Now, if your file already has one,

you won't see this error flagged

but I'm going to go ahead

and add a line just for good measure

and now I'm all set.

So notice in the sidebar,

the color for the file name has changed to yellow

and the number's gone down to two,

which just is logging the two warnings that I have.

Because it's not red, I know there's no errors.

So I'm going to save those changes

and so I could go over to eslintrc

if I ever wanted to find rules

that would override the style guide I'm using.

So there's documentation on how to add those

into rules down here as key-value pairs.

But especially when I'm using ESLint

in the editor, it can be useful to turn off errors

on a line-by-line basis.

And ESLint supports doing this with comments,

either on the same line

or on the line before.

So for my first console.log statement,

I'm going to turn off the warning

by adding an inline comment to the end of the line.

And I have this as a code snippet

on the wiki page for this video,

ESLint inline comment.

But I'm just going to type it in.

So at the end of that line,

I'm going to do a single space, double slash

and then eslint-disable-line no-console.

And so I'm saying here ESLint disable checking

on this line for the no-console rule.

And now that yellow underscore is gone

because even though I've violated the rules,

I've also included a directive saying

don't bother checking this.

Don't flag this for me, I'm good.

I can also add a comment on its own line

and have it apply to the line after it.

Now, I have another flagged console.log statement,

so I'm going to add a blank line before it

and then I'm going to add a comment.

And this is going to be eslint-disable-next-line

and no-console as the rule to disable.

And so now that underline goes away

from the line that follows

from that following console.log statement.

And my file list is back to its default color.

It's tracking now just the changes

that I've made in Git,

and it's got no tally of issues.

And so I've indicated here

that even though this particular file varies a bit

from my specified styles, I'm okay with it.

(upbeat music)