Subtitles section Play video
(lively music)
- [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)