Trunk Check makes it easy to write better code: we integrate dozens of linters, formatters, and static analyzers, so that you can focus on writing code instead of worrying about whether you're checking
NaNs correctly or accidentally casting pointers to booleans. Trunk Check is also a platform to write your own custom checks and integrate them to run as part of your repo's check suite. Use it via
trunk check and
trunk fmt on the command line, the Trunk VSCode extension, or the Trunk GitHub Action.
|Formatters||Enforce consistent style guidelines (e.g. wrap on 80 columns)|
|Linters||Static analysis for potential issues (e.g. were API keys checked in? is |
We currently support over 75 unique linters and we are adding new and updating old linters every sprint.
Trunk Check distinguishes new from existing issues, which allows you to introduce new linters and checks without any hassle.
This is traditionally a very painful process, because running a new linter or check in your CI means that you have to either fix all existing issues, which requires a huge upfront time investment, or only run the check on modified files, which adds unpredictable overhead to PRs and discourages engineers from making simple changes like typo fixes.
By integrating with Git, Trunk Check can hold-the-line: that is, it allows you to leave existing issues alone, and simply enforces that you never introduce new lint issues in a pull request.
Formatting linters behave slightly differently under hold-the-line than other tools. Since formatters apply to entire files they will be run across the entirety of any changed file and their recommendations must be applied before landing.
src/adder.js, which has 12 pre-existing issues, has a typo in a comment:
// Thsi method adds too numbers together
Engineer sees this typo and corrects it:
// This method adds two numbers together
Engineer pushes this super-simple, no-code-change Pull Request (PR)
PR is checked for formatting/lint issues on CI
- Engineer receives fail-mail and fail-slacks about their PR
- Engineer wonders what in the world could've failed in a PR that fixes a typo in a comment
- Engineer opens the failure notifications and starts going down the rabbit hole
- 2 hours later, engineer finally understands how much work it would be to fix all the pre-existing
- Engineer abandons PR
- Not only has a good chunk of the day been blown, but now the engineer is significantly less
inclined to ever do this in the future
trunk checkCI succeeds on their PR
- Engineer merges their PR
Trunk Check currently supports over 75 linters, each of which has it own issue severity classification system. We surface these as either Low, Medium, or High priority. This is not always a 1-to-1 translation of the linter's natively defined severity - many have more than 3 severity levels - but we've found that this provides the best signal for the end user.
By default, all issues reported by a linter are considered when evaluating if a pull request is
passing. We have taken this approach because
trunk is presenting a holistic view of a codebase, across all its languages and technologies, and we don't believe
trunk should be in the business of making severity recommendations for individual linters.
If a linter believes an issue is worth reporting, we consider it worth blocking for. If that issue is not interesting for your repo - we suggest you completely disable that rule for that linter in its configuration.
Updated about 1 month ago