Comment on page
Check
Trunk Check runs 100+ idiomatic code-checking tools for every language and technology, locally (CLI, VS Code Extension), on CI (CI, GitHub Bot), and in our web app. You're probably already running a few of these tools (eslint, prettier, etc), but Trunk Check adds valuable features to let you integrate with CI and PRs, run them faster, upgrade them easier, integrate them with CI and PRs, version them better, and much more.
Check handles:
- Autoformatting code, config files, IaC, and more
- Linting
- Static Analysis
- Optimizing images
- Flagging leaked secrets
- Flagging open-source dependencies with vulnerabilities
'Hold the line' is a Trunk Check feature that works for all tools Trunk Check runs. It detects which issues are preexisting or not, in a sophisticated way (we correctly handle the cases in which you modify one line of code and it causes new issues downstream of that). By default, we only call new issues "blocking issues" for the purposes of gating PRs and running
trunk check locally.This is the #1 feature driving why large companies purchase Trunk Check licenses. If you turn on a new linting rule without this, it may counter-intuitively increase your tech debt. This typically happens because you force every modified file to be clean of errors in pull requests. In real life, this means devs optimize for touching as few files as possible to avoid cleaning up all the issues they didn't affect. Things like renaming a class or function across many files will never be done, because a simple find+replace turns into an effort of fixing a hundred lint issues just to merge it. Plus, fixing unrelated issues to your changes is just a poor separation of responsibilities for pull requests.
In the world of code checking, more is more! Let's say you have a mostly javascript/typescript repo, so your package manager ecosystem is npm. You have other technologies in the repo though, maybe some bash scripts, dockerfiles, kube config, ci yaml, and all of those technologies have great checking tools that you could be running, but some are golang, some are direct downloads, some are python, and they aren't available on npm. You don't want to bring a bunch of new package managers into your repo for these 1-off tools. That's where Trunk Check comes in. You version these tools in
.trunk/trunk.yaml, and trunk can fetch them and run them from all the package managers or direct downloads you don't use in your repo.Trunk Check has a daemon that checks code as you modify files in your repo, runs linting in batches, and caches off the results for many linters. Since it's git-aware, it knows what you've changed, and by adding batched execution and caching, you end up with a much faster and smoother way to run these tools.
PR iterations kill productivity. Every time a dev updates a PR, even trivially, they have to context switch, break out of flow, reviewers also context switch to look at it, and that's not to mention the CI time to run a new suite of jobs.
- does everything from formatting, to linting, to security checking, to optimizing images
- config-as-code (
.trunk/trunk.yaml) - caching
- pre-existing issue detection
- a daemon & language server
When you modify a file, Trunk Check has a feature called Hold The Line, which only flags the new issues. It does this by being git-aware and using sophisticated heuristics (to handle the case where you change one line of code and new issues pop up somewhere else because of it).
This feature is critical for eng orgs because it allows you to start leveling up your codebase without making devs fix every preexisting issue in every file they touch, which would dramatically slow down development and cause a lot of frustration. Without this feature, it's impractical to turn on new rules in existing code-checking tools, but it's also impractical to add new tools to your code-checking arsenal. With it, adding a new tool is as easy as
trunk check enable {linter}, and you can start being better going forward and tackle your tech debt incrementally, on your own terms.Enable the following tools:
trunk check enable {linter}
Technology | Linters |
|---|---|
All | |
Ansible | |
Bash | |
Bazel, Starlark | |
C, C++ | |
CircleCI Config | |
Cloudformation | |
CSS, SCSS | |
Cue | |
Docker | |
Dotenv | |
GitHub | |
Go | |
HAML | |
HTML Templates | |
Java | |
Javascript | |
JSON | |
Kotlin | |
Kubernetes | |
Lua | |
Markdown | |
Nix | |
package.json | |
PNG | |
Protobuf | |
Python | |
Renovate | |
Ruby | |
Rust | |
Scala | |
Security | |
SQL | |
SVG | |
Swift | |
Terraform | |
TOML | |
Typescript | |
YAML |
- 1.
- 2.
Trunk downloads everything it needs to run on demand and caches it in
~/.cache/trunk. We run linters in parallel, in the background, and function as a language server to show results inline in VSCode via the [Trunk VSCode Extension][vscode].The
trunk command line tool runs locally on your developer machine, right where your code is. Later, you can automatically scan your repo using Trunk Check Cloud.Check will automatically keep tools up to date, suggest standard tools for your project type (eg:
clang-format for C++, eslint for JS/TS), and pin versions in trunk.yaml to ensure Trunk Check is reproducible.bash
bash (no prompts)
brew
npm
pnpm
yarn
curl https://get.trunk.io -fsSL | bash
curl https://get.trunk.io -fsSL | bash -s -- -y
brew install trunk-io
npm install -D @trunkio/launcher
pnpm add -D @trunkio/launcher
yarn add -D @trunkio/launcher
From the root of a git repo, run:
trunk init
This will scan your repository and create a
.trunk/trunk.yaml that enables all the linters, formatters, and security analyzers that Trunk Check recommends. For more details, see here.trunk is git-aware, so without further arguments, it will run on the files you've changed in your repo:trunk check
Note: if you have not modified any files,
trunk check will not check anything. See the CLI usage docs for more info on basic trunk usage.Last modified 2h ago