How to create your own shared esLint, prettier and stylelint configuration
Linters and code formatters make a developer’s life easier. They help you to follow coding and formatting standards, without constantly thinking about it. Or in other words, based on the great work the authors Sendhil Mullainathan and Eldar Shafir (Scarcity: Why Having Too Little Means So Much Kindle Edition): They reduce the tax on the cognitive bandwidth (bandwidth tax) and developers can focus on other actions.
Let’s take a look at the different coding styles, linters and the formatter prettier. How you can create your own configuration and use it in all your projects will be covered in this article. Let’s first talk about the basics.
Code Style Standards
What is a style guide and why do you need one?
Basically, a coding style guide is a set of rules, that define how proper code should look like and how it should be organized.
Why do you need one? Consider the following scenario. Three developers work for your company. John, Dan, and Jane. Each of them writes code differently. John prefers spaces, Dan tabs and Jane does not care. But Jane prefers semicolons, whereas the other two do not. That is fine, as long as they work on their own code. In the context of the company, it does not. It makes maintaining and working on the same codebase further difficult. Things get confusing very quickly as a result. That is where style guides come in very handy.
Guides align the code style of different developers and provide a ruleset each of them has to follow. Especially new project members should profit. Get up to speed, write code that others understand quickly should be a positive outcome for instance.
In the past, I stumbled upon several styling guides. Let’s take a look at three of them. Note, I did not use all of them myself. Afterwards I will explain how you can create your own.
You can explore Airbnb’s style guide on GitHub.
They promise “No decisions to make. No .eslintrc, .jshintrc, or .jscsrc files to manage. It just works.”. You can explore the standard style guide here. The ESLint configuration is available on GitHub.
We have seen a list of code styles by now. Let’s take a look at the linters. What exactly is a linter?
A linter or lint refers to tools that analyze source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. (source)
Considering the following example: You had a misspelled variable named
house in your code. You run it in your browser, it breaks and you open the console. The browser console reports an
Uncaught ReferenceError: hous is not defined error. You go back into your editor and notice that you have used a variable named
hous instead of
house. At this point you, probably wasted some minutes already. A linter would have caught this bug immediately. You would have fixed it and move on faster.
This article is not about judging which does the better job, but about how to configure your own shared config. So feel free to install them and try it yourself.
Now the time has come to start creating your own configuration. How should you start? What are the most important rules you have to worry about? A lot of questions might pop up in your head.
Don’t worry. Some talented developers racked their brains about it for you already. This is especially true for standard and Airbnb. What’s good about their default configuration is, that you do not have to think about all available ESlint rules. But what if you want to customize, remove or loosen some of the rules, create a custom one instead. You can do it.
ESLint published an easy to follow tutorial about how to create a shareable config. We will take a brief look at it now.
1) Create a shareable ESLint config
Shareable configs are simply npm packages that export a configuration object. To start, create a Node.js module like you normally would. Make sure the module name begins with eslint-config-, such as eslint-config-myconfig.(source)
Let’s take a look at how we can apply this. First of all, create a new index.js file and export an object containing your settings:
This will tell the linter that
MyGlobal is a global variable and needs no further declaration. Additionally, we defined that a semicolon is always required.
That’s it. You have just created your own ESLint config. Congratulations!
2) Publish the shareable config
Once you are happy with all the rules you have defined, you can push it to GitHub and/or publish it on npm and share it with others. If you want to test it locally first, you can use npm link:
npm link eslint-config-myconfig.
This is how the package.json can look like:
files property I described the entries to be included when the package is installed as a dependency (relevant when published on npm). In this case:
index.js, prettier.config.js, stylelint.js, and
stylelint.config.js. index.js contains the ESLint configuration, and stylelint.js exports the one for Styelint (covered later).
As you can see it in my configuration, think about adding ESLint and other linters as a peerDependency as ESLint suggests.
3) Use a shared Config and overwrite defaults
Now, let’s use it. All you have to take care of is, that the config is available as a dependency. Either as a npm module or you install it from GitHub directly. Example:
Rules (globals, rules, etc.) of the base config are now applied in your current configuration. You can extend the base config or even overwrite rules. Just add new
globals. Similar to:
extends can be a string or an array of base configurations. In my shared configuration it looks like this:
extends: ['airbnb', 'prettier', 'prettier/react']. Which means I applied rules from multiple configurations.
Some noteworthy base configurations, I stumpled upon are:
- eslint-config-airbnb: This package provides Airbnb’s .eslintrc as an extensible shared config.
- eslint-config-last: opinionated ESLint config which incorporates Prettier for even better code formatting and unification.
- eslint-config-prettier: you will read more about it in the next chapter
4) Finish Line and Advanced Configuration
Voilá, you are done! You just created your very first shared ESLint configuration.
You can configure even more than just
- Parser: by default ESLint uses Espree. One can also use babel-lint (a wrapper for babel-parser). It allows you to lint ALL valid Babel code with ESLint.
- Environment: It defines global variables that are predefined (eg. browser, node, jest, …).
- Plugins: Plugins usually export additional (custom) rules. For instance, you can define custom rules for jest with eslint-plugin-jest. You can read more about working with plugins here.
You can find a comprehensive list of parsers, plugins and more here: https://github.com/dustinspecker/awesome-eslint.
Let’s take a look at the next chapter, the formatter Prettier.
Your own shared Prettier configuration
Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary. (source)
I do not want to dig too deep into the “What is prettier” topic. In this article, we will just focus on the how to create a shareable configuration and use it together with ESLint. To me prettier is an awesome tool enabling me to focus more on coding, not too much on formatting my code.
A simple prettier configuration would look like this:
That’s it. No more configuration needed. Because prettier does not support many more rules. That might sound “bad”, but actually it is pretty awesome and the power of prettier. Instant code formatting. Set up in minutes.
Create a shared Prettier Configuration
Using a shared prettier config is as easy as (source):
Installing it directly from GitHub would look like this in my case:
git+ssh://firstname.lastname@example.org/natterstefan/eslint-config-ns.git. And the prettier.config.js would export
Use Prettier together with ESLint
Using prettier together with ESLint is luckily very easy. You just install eslint-plugin-prettier and eslint-config-prettier. The plugin will allow ESLint to use prettier as a code formatter for
eslint --fix. The config module will disable rules that conflict with Prettier’s configuration. Add them to your eslint config and you are done. Other developers are also very happy about it.
Note: While it is possible to pass options to Prettier via your ESLint configuration file, it is not recommended because editor extensions such as prettier-atom and prettier-vscode will read .prettierrc, but won’t read settings from ESLint, which can lead to an inconsistent experience. (source)
If you use ESLint, check the “ESLint Integration” checkbox and *poof*, everything should work (we use Kent Dodds’s prettier-eslint plugin under the hood). We will recursively search up the file tree for your package.json and ESLint settings, and use them when formatting.
prettier/prettier to your ESLint configuration should be sufficient.
Let’s take a look at what we have learned so far. We have seen what coding styles exist and what they are about. We have created a shareable ESLint config and made it work with prettier. What’s left is creating a configuration for (s)css with stylelint.
Your own shared css linter configuration
Create and Publish a shareable Stylelint Config
Luckily many of the steps mentioned above work for stylelint as well. Stylelint’s approach to create shareable configurations works pretty similarly. This is also due to the same structure of their stylelint.config.js. Take a look at mine:
I have extended
style-lint-config-sass-guidelines and added three additional rules. The last one supports BEM-naming patterns. I have found some other interesting base configs, but have not tried them yet:
- stylelint-config-prettier: Turns off all rules that are unnecessary or might conflict with Prettier.
- stylelint-config-recommended: It turns on all the possible errors rules within stylelint. Use it as is or as a foundation for your own config.
- stylelint-config-standard: Turns on additional rules to enforce the common stylistic conventions found within a handful of CSS styleguides, including Google’s CSS Style Guide, Airbnb’s Styleguide and others.
Publishing, installing and using the stylelint configuration works pretty similar to the process already described for ESLint configurations. Once you have installed it, you can use it in your
extends: 'eslint-config-ns/stylelint. Take a look at my example from react-trello-multiboard. Even overwriting and adding rules works similar. Sounds great, right?
Have you created your own shared configuration already? Are you using one on your company? Or do you have other insights for me? Let me know in the comments below or on Twitter.