One linter to rule them all
Keeping a repository clean across multiple languages usually means wrangling a stack of different linting tools, each with its own configuration and quirks. The GitHub Super Linter, now open sourced by GitHub's DevOps Engineering team, packages those tools into a single Docker container that runs as a GitHub Action. It was built to keep internal docs and code consistent, but it's available now for any repository on GitHub.com.
What it does, in short: every time a pull request is opened, the Super Linter runs against the changed code and reports results via the Status API. Passing or failing is visible right on the PR, and if there are errors, the developer sees exactly where and what they are. Fix them, push again, and the linter re-runs—repeating until the code is clean. Branch protection rules can be set so nothing merges until checks pass.
Beyond that, it aims to:
- Keep broken code from landing on master branches
- Enforce coding best practices across languages
- Define consistent code layout and formatting
- Automate part of the review process so humans can focus on substance
What's covered
The container currently supports a broad set of languages, and the list is still growing—check the README.md in the repository for the full, current catalog. It's especially useful for monorepos, where several languages and documentation formats live side by side.
Customization is built in via flags and templates. Repositories can supply their own rule sets, and detailed instructions live in the Super Linter wiki.
Default rules, your rules
It's impossible to please every developer with one rule set, so the Super Linter is designed to let you override anything. If you don't provide your own configuration, it falls back on sensible defaults.
For Ruby and Rails, that means the rubocop-github gem—the same rules and versioning used on GitHub.com itself. For other languages, the defaults come from the tools themselves where possible (like coffeelint or yamllint), or from a balanced baseline that establishes decent groundwork, as with Markdownlint and pylint.
What that gives you is a working foundation out of the box. If your team wants stricter or looser rules, just copy a template from the TEMPLATES folder into your repository and adjust to taste.
Getting involved
The tool is open source, and the project is actively looking for contributions—whether that's improving existing best practices, adding support for new languages, or making the whole thing easier to consume. If you want to pitch in, the contributing guide in the repository has the details.
