Standard

<img src="https://user-images.githubusercontent.com/79303/233717126-9fd13e6d-9a66-4f1c-b40c-fe875cb1d1b4.png" style="width: 100%"/>

The standard gem brings the ethos of StandardJS to Ruby. It's a linter & formatter built on RuboCop and provides an unconfigurable configuration to all of RuboCop's built-in rules as well as those included in rubocop-performance. It also supports plugins built with lint_roller, like standard-rails and standard-sorbet.

Standard Ruby was created and is maintained by the team at Test Double, because we appreciate the importance of balancing predictable, consistent code with preserving developer autonomy. 💚

Topics covered in this README:

• Wait, what?!
• Basic usage
• Editor & CI integrations
• Ignoring errors
• Configuration options
• Plugins and extensions
• Community

Wait, did you say unconfigurable configuration?

Yes, Standard is unconfigurable. See, pretty much every developer can agree that automatically identifying and fixing slow, insecure, and error-prone code is a good idea. People also agree it's easier to work in codebases that exhibit a consistent style and format. So, what's the problem? No two developers will ever agree on what all the rules and format should be.

This has resulted in innumerable teams arguing about how to configure their linters and formatters over literal decades. Some teams routinely divert time and energy from whatever they're building to reach consensus on where commas should go. Other teams have an overzealous tech lead who sets up everything his favorite way and then imposes his will on others. It's not uncommon to witness passive-aggressive programmers change a contentious rule back-and-forth, resulting in both acrimony and git churn (and acrimony about git churn). Still, most developers give way to whoever cares more, often resulting in an inconsistent configuration that nobody understands and isn't kept up-to-date with changes to their linter and its target language. Whatever the approach, time spent bikeshedding is time wasted.

But you can't configure Standard Ruby. You can take it or leave it. If this seems presumptive, constraining, and brusque: you're right, it usually does feel that way at first. But since 2018, the Ruby community has debated Standard Ruby's ruleset, ultimately landing us on a sensible set of defaults that—while no one person's favorite way to format Ruby—seems to be good enough for most of the ways people use Ruby, most of the time.

If you adopt Standard Ruby, what's in it for you? Time saved that would've been spent arguing over how to set things up. Also, seamless upgrades: we stay on top of each new RuboCop rule and update our configuration on a monthly release cadence. But the best part of adopting Standard as your linter and formatter? You'll spend a whole lot less time thinking about linters and formatters.

So please, give Standard Ruby a try. If you're like these folks, you'll soon realize that the value of a linter is in using one at all and not in the particulars of how it's configured.

Usage

Install

Getting started is as easy as gem install standard or throwing it in your project's Gemfile and running bundle install:

gem "standard"

Running Standard Ruby

Once installed, you can run Standard from the command line via its built-in executable or as a Rake task.

Standard Ruby's binary is named standardrb to distinguish it from StandardJS:

$ standardrb

And the Rake task can be run if your Rakefile includes require "standard/rake". This will load the standard task, allowing you to run:

$ rake standard

Either way, Standard will inspect any Ruby files found in the current directory tree. If any errors are found, it'll report them. If your code is standard-compliant, it will get out of your way by quietly exiting code 0.

Fixing errors

A majority of Standard's rules can be safely fixed automatically.

# CLI
$ standardrb --fix

# Rake
$ rake standard:fix

Because we're confident Standard's fixes won't change the behavior of our code, we typically run with fix enabled all the time because it saves us from having to look at and think about problems the computer can solve for us.

Applying unsafe fixes

There are a number of other rules that can be automatically remedied, but not without the risk of changing your code's behavior. While we wouldn't recommend running it all the time, if the CLI suggests that additional errors can be fixed unsafely, here's how to do that:

# CLI
$ standardrb --fix-unsafely

# Rake
$ rake standard:fix_unsafely

So long as your code is checked into source control, there's no mortal harm in running with unsafe fixes enabled. If the changes look good to you and your tests pass, then it's probably no more error prone than manually editing every change by hand.

Integrating Standard into your workflow

Because code formatting is so integral to programming productivity and linter violations risk becoming bugs if released into production, tools like Standard Ruby are only as useful as their integration into code editors and continuous integration systems.

Editor support

We've added a number of editing guides for getting started:

• Atom
• emacs
• Helix
• neovim
• Nova
• RubyMine
• vim
• VS Code
• Zed
• Sublime Text

If you'd like to help by creating a guide, please draft one in an issue and we'll get it added!

Language Server Protocol support

If you don't see your preferred editor above, Standard Ruby also offers robust language server support, in two ways, both included with the standard gem:

1. A Ruby LSP add-on, which (if the standard gem is in your Gemfile) will be loaded automatically
2. A language server executable, which can be run from the command line with standardrb --lsp

| Capability | Ruby LSP Add-on | Internal Server | | ------------- | ------------- | ------------- | | Diagnostics (Linting) | ✅ (Pull) | ✅ (Push) | | Formatting | ✅ | ✅ | | Code Actions | ✅ | ❌ | | Everything else | ❌ | ❌ |

Due to the advantages of Pull diagnostics and its inclusion of Code Actions ("Quick Fixes" in VS Code parlance), we recommend using Standard's Ruby LSP add-on where possible.

Regardless of which language server you use, many editors have added LSP support, with each bringing their own approach to configuration. Many LSP features should "just work", but when in doubt, please consult our editor guides above as well as your editor's own documentation on how to configure LSP formatters and linters.

CI support

Various continuous integration and quality-checking tools have been made to support Standard Ruby, as well.

• GitHub Actions
• Code Climate
• Pronto
• Danger

Of course, no special plugin is necessary to run Standard Ruby in a CI environment, as standardrb and rake standard work just fine on their own!

Other tools

These tool integrations are also available:

• Guard
• Spring

Ignoring errors

While Standard is very strict in how each formatting and linting rule is configured