Image: GitHub

GitHub has released an open source tool called “super linter,” which it says could make testing code for errors and inconsistencies easier than ever.

Linters are tools that scan source code for bugs, formatting errors, poorly built constructs, and other problems that can result in messy, inefficient code.

Traditionally, a separate linter is needed for each language used in an application, leading to a lot of time spent manually operating what are supposed to be time-saving automation tools. “Setting up a new repository with all the right linters for the different types of code can be time consuming and tedious,” said GitHub’s Lucas Gravely in a blog post.

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

GitHub’s super linter began life as an internal tool of the GitHub Services DevOps Engineering team, and was built “to maintain consistency in our documentation and code while making communication and collaboration across the company a more productive experience.”

GitHub describes the goals of the super linter to be:

  • Preventing broken code being uploaded to master branches,
  • Establishing cross-language coding best practices,
  • Building a single set of guidelines for formatting and layout,
  • Automating the linting process to speed up code reviews,
  • Shipping better code.

The super linter itself is a code repository packaged into a Docker container, and anyone with a repository on GitHub can call it up using a GitHub Action as detailed in the super linter’s readme.

There are plans to continually add new language support to the super linter; as of now it supports 16 linters that can review code written in Ansible, CSS, CoffeeScript, Dockerfile, Golang, JavaScript, JSON, Markdown, Perl, Python3, Ruby, Shell, Terraform, TypeScript, XML, and YAML.

The super linter can be configured to run any time a pull request is opened. “It will let you know if any of your code changes passed successfully, or if any errors were detected, where they are, and what they are. This then allows the developer to go back to their branch, fix any issues, and create a new push to the open pull request,” Gravely said.

The super linter can be customized in a variety of ways as well, like requiring all code to pass a linting in order to be merged, disabling certain rules or individual linters, and tweaking environment variables.

There are some restrictions to using the super linter, though:

  • Because it’s packaged at run time dependencies can’t be updated, nor can individual linters be updated.
  • The super linter doesn’t read additional details from JSON packages.
  • Users can’t download additional codebases from private repositories to use as dependencies.

It is, however, possible to download and run super linter locally, which may or may not allow users to bypass restrictions placed on the GitHub-hosted version.