Package Exports
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (@trunkio/launcher) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
Trunk
🎉 Trunk is in beta. We'd appreciate your feedback - stop by the Trunk Community Slack and let us know what you think. Thanks!
Trunk is a blazingly fast meta code checker and formatter with extraordinary features like caching, preexisting issue detection, a daemon, and a language server. It's managed completely via config-as-code, so you can easily pin your repo to specific versions of your linters, formatters, and static analyzers.
Don't install a dozen different linter and formatting plugins, just use Trunk. Level up your code quality and consistency today.
Get Started
- Install Trunk →
npm install @trunkio/launcher(docs) - Setup Trunk in your repo →
npm exec trunk init(docs) - Take Trunk for a spin →
npm exec trunk check --sample
That's it!
Prereqs
None! Trunk manages linters and formatters for you via pinned versions in your repo's
.trunk/trunk.yaml file. You don't need to install any linters or configure the extension in any
way. We cache linters, formatters, and runtimes in ~/.cache/trunk. Using a linter distributed as a
go module but you're not a go user? Don't worry about it, we handle it all 😉.
Linters / Formatters
We integrate new linters every release. Stop by on slack and let us know what you'd like next!
| Language | Linters |
|---|---|
| All | gitleaks |
| Ansible | ansible-lint |
| Bash | shellcheck, shfmt |
| Bazel, Starlark | buildifier |
| C/C++ | clang-format, clang-tidy |
| Cloudformation | cfnlint |
| Docker | hadolint |
| GitHub | actionlint |
| Go | gofmt, golangci-lint, semgrep |
| HAML | haml-lint |
| Java | semgrep |
| JS/TS | eslint, prettier, semgrep |
| Kotlin | detekt, detekt-explicit, ktlint |
| Markdown | markdownlint |
| Protobuf | buf-breaking, buf-lint |
| Python | autopep8, bandit, black, flake8, isort, pylint, semgrep, yapf |
| Ruby | brakeman, rubocop, rufo, semgrep, standardrb |
| Rust | clippy, rustfmt |
| SQL | sql-formatter |
| Terraform | terraform, tflint |
| TOML | taplo |
Linting and formatting principles
- Autoformat every file. Every file.
- Every file in your repo should have at least one tool checking its validity
- You should always get the same results locally as on CI
Features
Configuration
Trunk manages all configuration as code in your repo's .trunk/trunk.yaml file. When you first
trunk init, we scan your repo for which linters and formatters are applicable to you and set up an
initial .trunk/trunk.yaml file for you to use. See the docs for more
details.
Formatting
Don't install 15 formatters, just use trunk
Ever hit one of these problems?
- Struggling to figure out why you need a Go or Ruby installation to run a specific formatter
- Devs on your team all get slightly different formatting results because you're running different versions of the formatters
- Your formatting doesn't match what your CI lint job is expecting because you're running a different version of a formatter locally
That's what formatting via Trunk solves. Everyone on your team is guaranteed to get the same results, because we always run the same version of each formatter/linter on everyone's machine, including in your CI lint job.
Extras: VSCode Extension & GitHub Action
- Use a single extension for all your linting and formatting → Trunk VSCode Extension
- Protect lint and format issues from leaking into main → Trunk GitHub Action
How versioning works
After you trunk init, trunk.yaml will contain a pinned version of Trunk to use for your repo.
When you run trunk, it will automatically detect which version you should be running for a
particular repo and, if needed, download it, then run it. The trunk VSCode extension works the same
way: regardless of what repo you're in, the underlying version of trunk it runs is based on the
pinned version in your trunk.yaml file. Config-as-code 👍.
This means that everyone working in a repo, using the trunk cli, the VSCode extension, or when
running on CI, all get the same results because they're running the same version of trunk and the
same versions of all the linters/formatters. No more "doesn't happen on my machine". When you want
to upgrade to a newer version, just run trunk upgrade and commit the updated trunk.yaml.
Development Status
We release new versions about every other week.
Feedback
For support and feedback, reach out on our Trunk Community slack. Thanks! ❤️