ESLint, Prettier, and StandardJS – An Overview

I recently tuned into some Twitter chatter about Prettier and StandardJS, and how they relate to ESLint. If you’re new to these packages (like me), you may have some questions. What’s the difference between all these tools? Do I use them individually, or together? How do they add value to my project?

Hopefully this post will answer a few of your questions and clear up some of the basics.

What is a Linter vs. a Formatter?

Let’s start with terminology. A linter analyzes code quality. A formatter formats code to meet certain style requirements.

At a high level:
– ESLint is a linter that contains code quality and formatting rules
– Prettier is a formatter
– StandardJS is a little of both

So, the tools are not completely interchangeable, but they can work together in some situations (more on that below).

Why Not Just Use ESLint?

At this point you might be questioning why other tools exist at all, if ESLint can handle formatting. Using one tool for both is certainly an option, but it’s been suggested that formatting and code quality are two completely separate concerns. Formatting is important, but developer time is better spent on addressing the code quality issues that lead to bugs.

One big advantage of Prettier is that all rules can be auto-resolved*. One npm script can fix all style issues at once, and a smart precommit hook can do that automatically. This could mean that no one on the team has to think about style while they push changes, which sounds awesome.

*ESLint has the --fix option, but not all rules can be automatically fixed.

What Is StandardJS?

As stated above, StandardJS isn’t purely a linter or a formatter. It’s essentially a CLI wrapper around a specific, opinionated group of ESLint rules. The idea behind this is to standardize a set of rules that help developers write code more efficiently. These rules can’t be (easily) overridden, which may help alleviate the problems of team bikeshedding around individual style rules. Mind you, the decisions are still being made by someone, but if you agree with the methodology of those decisions it could be a great option.

To be clear, this is really standalone* alternative to ESLint. There probably aren’t many situations where you’d use the two together, and it would be kind of contrary to the spirit of StandardJS.

*Like ESlint, StandardJS comes with a --fix option that fixes _some_ rules, but not all. There’s another popular package out there called prettier-standard that combines the advantages of both StandardJS and Prettier.

Okay, But What Should I Use?

Ultimately this is up to you, but I’ve compiled a few formatting options using the packages discussed in this post. This is by no means a comprehensive list, and ultimately should be informed by your teams’ needs. But I think a valid argument can be made for any one of these, depending on the situation.


  • Everything in a single report.
  • Highly configurable – risk of style bikeshedding and override creep.
  • Provides a --fix option for some rules.

ESLint + Prettier

  • Separation of concerns: code quality and formatting.
  • Formatting issues can be autofixed by Git hooks or CI.
  • Packages like prettier-eslint can help with integration.
  • Prettier handles multiple languages, not just JavaScript.
  • Two separate configurations to manage.
  • Possibility of formatting overlap if ESLint rules aren’t managed well.


  • Simple to use – no easy access to configuration.
  • Extremely opinionated style guide.
  • Provides a --fix option for some rules (based on ESLint).
  • Can integrate with Prettier using packages like prettier-standard.