Standard Ruby: An Unconfigurable Linter and Formatter for Ruby

The problem Standard Ruby solves: bikeshedding over RuboCop configs

RuboCop ships with a large set of rules and, by default, expects you to decide which ones to enable and how. The README describes the result: teams diverting time from building software to reach consensus on where commas go, overzealous leads imposing their favorite configuration, and rules changed back and forth until the config is inconsistent and out of date. Standard Ruby's answer is to remove the decision. The gem provides what its README calls an "unconfigurable configuration" covering RuboCop's built-in rules plus rubocop-performance. You can take it or leave it.

The target user is a Ruby team that would rather have one style than the best style. The README is explicit that the ruleset is not anyone's favorite way to format Ruby, only what the project considers good enough for most Ruby code most of the time. That framing matters: if your team has a strong, settled opinion about a particular cop, Standard Ruby is not a compromise you can tune, it is a package you accept or reject.

How Standard Ruby works: a fixed RuboCop configuration plus lint_roller plugins

Standard Ruby is not a new linter. It is a wrapper around RuboCop that ships a pinned configuration. The repository layout reflects this: config/ holds the base YAML files, lib/ holds the Ruby code that loads and runs them, exe/ holds the standardrb executable, and the gemspec declares the dependency on RuboCop.

The README states that the base configuration covers RuboCop's built-in rules and those in rubocop-performance. Because the configuration comes from the gem rather than your project, a Standard Ruby upgrade can change which rules apply, which is why the project describes upgrades as seamless: you are not maintaining a list of cops yourself.

Extension happens through lint_roller, a plugin interface the project maintains. The README names two plugins built on it, standard-rails and standard-sorbet. That is the intended path for framework-specific rules: rather than editing your .standard.yml to enable a cop, you add a plugin that contributes its own configuration. The repository does include a .standard.yml at the top level, so the tool does read a project file, but the README's framing treats it as the exception rather than the main configuration surface.

Installing Standard Ruby and running your first lint and fix

The README gives two installation routes: a global gem install, or adding the gem to your project's Gemfile. The Gemfile route is the one that keeps the version pinned per project.

gem "standard"

After bundle install, the executable is named standardrb, not standard, to distinguish it from StandardJS. Running it with no arguments inspects Ruby files in the current directory tree and reports offenses. If the code is compliant, it exits with code 0 quietly.

$ standardrb

If you prefer Rake, add the require line to your Rakefile and the standard task becomes available.

require "standard/rake"

$ rake standard

Most rules have safe automatic fixes. The README says the maintainers run with fix enabled all the time, because the fixes are not expected to change behavior.

$ standardrb --fix

A smaller set of offenses can only be fixed unsafely, meaning the change could alter behavior. The README recommends running this only when the CLI reports that additional errors are available, and only with the code checked into source control so you can review the diff.

$ standardrb --fix-unsafely

A first real use looks like this: install the gem, run standardrb once to see the offense list, then run standardrb --fix and inspect the resulting diff before committing. If the CLI mentions unsafe fixes, decide case by case rather than running --fix-unsafely across the tree.

Where Standard Ruby gets in your way

The unconfigurable configuration is the whole point and also the main limitation. If your project has a house rule that conflicts with the bundled configuration, the README offers no supported way to change it. The documented escape hatches are narrower than they first appear: the README has an "Ignoring errors" topic, and plugins exist for whole frameworks, but neither is a general mechanism for rewriting individual cops to taste. The README does not document a supported path for overriding a single rule, and it does not document rollback if an upgrade changes the ruleset under you.

The unsafe fix path carries its own risk. The README's own guidance is that unsafe fixes may change behavior, and its suggested mitigation is source control plus passing tests. Projects with thin test coverage should treat --fix-unsafely as a manual review exercise, not a batch command.

The release history is worth noting. Recent releases listed for the project are v1.31.0 from 2023-08-19, v0.0.36.1 from 2023-04-05, and v1.25.0 from 2023-03-16. The version numbering in that list is inconsistent, with v0.0.36.1 sitting between v1.25.0 and v1.31.0, and the release titles show the project has had at least one packaging mistake it described as a mea culpa. The README claims a monthly release cadence for staying current with new RuboCop rules; the listed releases do not show a monthly rhythm, so treat that cadence as an intention rather than something the release list demonstrates. The repository is not archived, and the last push was on 2026-09-14.

Standard Ruby versus plain RuboCop

The honest alternative is RuboCop without Standard Ruby, and the difference is entirely about who owns the configuration. RuboCop gives you a .rubocop.yml you write and maintain, custom cops, per-directory overrides, and the ability to disable anything. Standard Ruby gives you a configuration you do not write and cannot meaningfully negotiate, on the theory that the argument costs more than the rules are worth.

The trade-off is concrete. With RuboCop alone you spend time on configuration and get exactly the style you want, including rules tailored to your domain. With Standard Ruby you spend that time on your product and accept a style that is, by the project's own admission, nobody's favorite. Neither position is unreasonable. A greenfield project with no strong style opinions and a small team gets more from the fixed configuration. A large codebase with an established .rubocop.yml, custom cops, or generated code that needs exemptions will find Standard Ruby's constraints more expensive than the arguments it prevents.

There is also a middle path in the plugin system. If you want Standard Ruby's defaults plus framework awareness, standard-rails and standard-sorbet extend the configuration through lint_roller rather than replacing it. That is narrower than full RuboCop configuration, but it covers the common case of Rails or Sorbet projects.

Maintenance cost, upgrades, and licence status

The maintenance argument for Standard Ruby is that you do not maintain a ruleset. The gem pins RuboCop and its configuration together, so upgrading Standard Ruby upgrades both. The cost moves to upgrade time: a new Standard Ruby version can change which rules fire, and the README does not document a rollback procedure or a way to pin individual rules during an upgrade. Teams that need a stable rule set across a long release cycle should check the changelog before bumping the gem.

The README lists editor integrations for Atom, emacs, Helix, neovim, Nova, RubyMine, and vim, plus CI integration guidance. That is a real maintenance surface: each integration is maintained separately, and the README links out to wikis and third-party repositories rather than bundling them.

The licence field for the repository is reported as NOASSERTION, which means the automated licence detection could not classify it. The repository does contain a LICENSE.txt file, so the terms exist in the tree. Anyone embedding Standard Ruby in a distributed product should read that file directly rather than relying on the repository metadata, and should not treat this description as legal advice.

Editorial conclusion

Adopt Standard Ruby if your team wants one Ruby style and no configuration debate, and you can live with the ruleset as published. Do not adopt it if you need per-project rule tuning, custom cops, or a style that diverges from the base configuration, since RuboCop gives you that and Standard deliberately does not. Before rolling it out, run standardrb on a branch and inspect the diff, then check the plugin list for standard-rails or standard-sorbet if your codebase needs them.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. standardrb/standard on GitHub