How to create your own shared esLint, prettier and stylelint configuration

Image for post
Image for post

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

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.

A mostly reasonable approach to JavaScript

One of the most widely used code styles (I use it too) was created by Airbnb. They cover a lot nearly all aspects of JavaScript. Hence, the default export contains all of Airbnb’s ESLint rules, including ECMAScript 6+ and React. They published a shared config for React and one without React plugins.

You can explore Airbnb’s style guide on GitHub.

JavaScript style guide, linter, and formatter

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.

A JavaScript source file is described as being in Google Style if and only if it adheres to the rules herein

You can read more about Google’s style guide here. The ESlint configuration is available on GitHub.

Linters

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 anUncaught 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.

In the past, I have tried ESLint, XO (their eslint-config) and standard for Javascript and stylelint (example configs) for css. All of them to a pretty good job. Some of them require further configuration (eg. .eslintrc.js or stylelint.config.js), and some not.

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.

Your own shared javascript linter configuration

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.

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!

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:

In the 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.

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:git+ssh://git@github.com/natterstefan/eslint-config-ns.git.

The shared config can then be applied by using the extends property in the .eslintrc.js file. This is how it would look like extends: 'eslint-config-ns, if you use my ESLint Config.

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 rules or 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:

Voilá, you are done! You just created your very first shared ESLint configuration.

You can configure even more than just globals and rules:

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.

Using a shared prettier config is as easy as (source):

Again, all you have to take care of is, that the base-config is available as a dependency. Either as a npm module or you install it from GitHub directly.

Installing it directly from GitHub would look like this in my case:git+ssh://git@github.com/natterstefan/eslint-config-ns.git. And the prettier.config.js would export require('eslint-config-ns/prettier.config').

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.

Attention

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)

After reading the documentation of prettier-atom (I use Atom), I am not sure if this is still a problem. prettier-atom states:

ESLint Integration
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.

So adding prettier/prettier to your ESLint configuration should be sufficient.

This option will merge and override any config set with .prettierrc files. Prettier also shared a documentation, which confirms my assumptions.

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

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:

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 stylelint.config.js like: 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?

Conclusion

Now it is up to you. Select your preferred code style (for both javascript and css), create your own configuration and start using it in all your projects. Work with it for some time and start adjusting the rules according to your needs later. But do not overdo it and overrule all of them. That would make nonsense of the creator’s hard work at some point.

If you are interested in getting to know my shared configuration, you can find my GitHub repository here and the npm module here. Examples of how I use my own configuration can be found in my react-trello-multiboard project, both javascript and css.

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.

Written by

I am a Software Engineer from Austria 🇦🇹. I write about JavaScript, TypeScript, ReactJS and NodeJS. 📧 Weekly NL Series: https://newsletter.natterstefan.me

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store