- [Instructor] One of the nice features
of ESLint is the ability
to extend an existing ESLint configuration.
These are known as shareable configs.
Practically, a shareable config is just an npm package
that exports an ESLint configuration object.
The name of the package must begin
with "enslint-config-"
then the name of the configuration.
Shareable configs can be published
on npm to share with others.
I always like the open source approach.
They can also be kept private,
which works well for organizational standards
that may include proprietary justification or context.
There are two steps necessary for using a shareable config.
First, add the package to the development dependencies
of the project and install it.
Then update the ESLint configuration
to include the extends property
and the name of the configuration that it extends.
For example, "extends": "enslint-config-myconfig."
There's a shorthand as well,
which leaves off the ESLint config.
So "extends": "myconfig"
will work the same and be nicer to look at.
ESLint includes a recommended configuration
which should be safe for most code bases.
To use it, add "extends:" "eslint:recommended."
It includes a number of logical rules
including possible errors,
best practices, variable use,
and ECMAScript 6 directives.
Let's update our project to use this configuration.
Return to visual studio code.
Let's open up the ESLintrc.js again.
Then let's add an extends after the ENV.
So with "extends:" "enslint:recommended"
and then don't forget the trailing comma.
The no empty rule is already included
with the ESLint recommended rules
so we can delete that line.
Let's save the file
and then let's recheck that file
with the updated configuration.
Let's close the eslintrc.js
and then reopen app.js so we have context.
Then down in the terminal type "MPX ESLint" space
and then app.js and press enter.
This time there are 14 errors and one warning.
A nice thing that it noticed is that both configuration
and next were assigned a value, but never used.
The feedback is getting more comprehensive.
Of course, ESLint isn't the only
available shareable configuration.
Here's three shareable configs to consider.
The Airbnb JavaScript and React Style Guide,
published on GitHub is incredibly comprehensive
and well-written.
I consider it a model for both the scope
and brief justifications for each rule.
There's the JavaScript standard style, also on GitHub.
It's intended to bike shedding discussions
that can distract from getting stuff done
and that's a great place to start.
Finally, the Google JavaScript Style Guide
on GitHub takes a very technical and formal approach.
There's crossover between all three,
so it's good to have a comparison.
For a more comprehensive list of ESLint plugins
and configurations,
check out Dustin Specker's list on GitHub.
Creating a shareable configuration
is the challenge at the end of this chapter.
But first I want to give some
recommendations from experience.
The official documentation for shareable configs
is a good reference.
A shareable config can extend another configuration,
even multiple configurations.
Same as what we did,
start with an existing shareable configuration,
then customize to meet your needs.
When starting with an existing one,
use the "package.json peerDependencies"
to specify any extended configs or plugins.
As a shared config is a package,
use semantic versioning,
including minor and major releases.
Finally, like any project,
include a read me with instructions
on how to get started and justifications.
It doesn't have to be long,
but it should be helpful to others.
If you're creating a private shareable configuration,
here's a couple tips to save you time.
Do not use Git submodules.
It will give you a headache
and it creates unnecessary exceptions.
Instead use the package manager
and treat it like any other package
because that's what it is.
Do use git+ssh to add them,
like "npm install git+ssh" and so forth
ending for the tag.
This way you can use a private repository
like any other package.
We've been linting a single file,
but how do we go about linting the entire code base.