Why Code Quality?
Last updated
Last updated
Most projects will run linters and formatters for their primary language but neglect to run any static analysis on the build scripts, IaC (infrastructure-as-code), CI (continuous integration) config, and docs files. These are the "hard to clean corners" of your code base, where coding standards fall apart and vulnerabilities accumulate unnoticed.
These bits of unlinted code accumulate unused dependencies, deprecated method calls, poorly formatted code, and known antipatterns, which will spread as your project ages from copy-pasting. They become bits of code that no one wants to touch or own.
Worse is the accumulation of . A 2017 study by Northeastern University aptly named : Analysing the Use of Outdated JavaScript Libraries on the Web revealed that 37% of 133,000 websites used a JavaScript library with known vulnerabilities. More recently, , 84% of 1,703 reviewed codebases had at least one such vulnerability.
Now factor in your IaC files, CI config, and build scripts; these are the places that you should lint regularly because of the likelihood of newly discovered vulnerabilities in your dependency chain. This is why you need a metalinter that can lint all of your files.
Having good linter coverage in any modern project is difficult because there isn't just one language and technology. There are tons of scripts, images, config files, docs, and IaC files to lint.
The tools required to lint everything install, run, output, upgrade, and configure differently. Now consider the tools that require dependencies and runtimes, such as and that depend on Go, or and that depend on Python. You have to maintain version pinned tools and their runtimes.
These tools are also prone to tool-rot, where dependencies become old, deprecated, or known vulnerabilities are discovered. In fact, . Keeping these tools up to date is a Sisyphean task. It's better to have a metalinter handle all of it.
Giant code bases are hard to lint without good tooling. Imagine introducing a new Python linter to lint over 1 million lines of code. No one will wait tens of minutes or hours for linters to run. Now, considering a polyglot mono repo with millions of lines of code and many languages, the problem only grows.
Trunk Code Quality solves this by being and linting only the lines and files that have changed in your repo on commit or PR.
adopted Trunk Code Quality to replace their because it's difficult to maintain. Writing a script that can do everything a metalinter does is not trivial. You need to handle per-line and file ignores properly, adapt to the many config and output formats of different tools, support different OS and architectures, lint in a way that's so it can run on large code bases quickly, and adapt to breaking changes or newly added linters.
That code is outside of a project's core goals and is bound to become debt. Code Quality is free to run locally and in CI, and reporting to the is free for open-source teams.
Trunk Code Quality lets them easily manage consistent config and tooling for their repo and achieve full linter coverage.
Popular open-source repos like and use Trunk Code Quality to lint their source code. They use Trunk Code Quality as their metalinter because it's difficult to maintain and run the many linters they run, especially when open-source maintainers need to run and install them individually.
.