- [Instructor] The ability to Lint the entire code base
is built into ESLint.
The trick is making it useful.
Switch back to VS code.
From the terminal we're going to use NPX to run ESLint
but this time we're going to specify dot,
which is the current directory,
press Enter.
Well, there's over 1000 errors
but a lot of these aren't actually in our custom code
and our false positives.
If I scroll up, contrib is third-party code.
This is a very real-world situation.
A single codebase can include
many different types of functionality.
Of course the Node.js application itself is included.
There's also tests,
which may use a different environmental configuration.
The front end may use different coding standards
such as supporting legacy browsers.
Finally, similar to testing
third-party code should be excluded
because you're not maintaining it.
To address this type of situation,
ESLint configuration files support a hierarchy.
ESLint will recursively look
for configuration files in a target.
If an additional configuration is found,
it will be used on that directory and its children.
When that happens,
ESLint will inherit the existing rules from the parent,
then locally override whatever else was specified.
Here's a practical example of what that looks like.
In the root of the project,
we've got a configuration that is optimized for Node.js.
Then in the public folder,
a second configuration removes Node.js support
and adds a browser friendly configuration.
Let's add that browser friendly configuration.
The completed file is in solutions 02/07 public subfolder,
named without a dot for convenience.
Let's see it in action by switching over to VS code.
In the Explorer view,
close routes if it's open and open up public,
then right click on public and go to new file.
Call the new file .ESLintrc.js and press Enter.
You can copy and paste or just type it out.
This is pretty short.
We'll start with an expression,
to return an object with a parentheses and a new object.
Then we're going to set the parser options,
so ''parser options' and then a new object.
Instead of a module, these will be script files.
So source type is set to script,
close the object and then follow it with a comma.
Next we'll set the environment.
So "ENV" then colon, and then new object.
This will be a browser.
So set browser to true.
We're also using jQuery to set that to be true.
So jQuery true,
and finally, since we're not using node
on the front end set node, two false.
Close out the ENV object, then add another comma.
We're also going to se some overriding rules
to support a theoretical
front end teams preferred use of our...
So rules set to new object
and then no dash far is going to be off.
Off then prefer dash const
is also going to be off.
Make sure the exported object is closed at a semi-colon
and save the file.
Switch back to the terminal.
Let's rerun the scan NPX space, IES, lint space dot.
This time, there are way fewer problems
but we're still getting warnings and errors from contrib.
What can we do about that?
- ESLint supports ignoring files and directories
in a special configuration file named .ESLint ignore.
Each line is a glob pattern to emit a pattern of files
and directories.
For example we'd like to exclude everything
within public slash contrib.
So just add an asterisk,
let's add an ignore file now.
The completed file is in the 02_07 exercise files
without the leading dot for convenience.
Ready to add this one line file?
Close our IES, lint RC.js,
and then in the root in Explorer, right?
Click and go to new file and call it dot ESGR lint.
Ignore with no extension and press Enter.
We only want to ignore one thing for now.
So type public/contrib/asterisk.
Save the file, then switch back to the terminal.
Reerun the scan with NPX ESLintd space and dot.
And this time with the ignore file in place.
Much more manageable,
there are now less than 50 errors and warnings now.
When linting an existing project,
it's good to have some practical goals.
Of course the top priority
is to detect and eliminate any fatal errors.
If you have a large existing code base,
avoid trying to fix all the errors in warnings at once.
This can wreck the file history in tools like Git,
and if you're not careful,
bugs can inadvertently get introduced.
Instead, I found that it's better to take a more
incremental approach and leave code better
than you found it.
Switching back and forth between VS code
and the terminal isn't impossible but it's kind of awkward.
How do we go about configuring VS code to use directly?