Local Linting
Last updated
Last updated
After initializing Trunk, you can begin scanning for issues in your repo, and decide whether to fix them up front, fix them incrementally as you code, or ignore irrelevant suggestions. This page walks through the process of linting locally and fixing existing issues.
After initializing Trunk Code Quality, you can run all tools on all files to look for existing issues. You can run Trunk on all files in your repo with this command. This will output all issues detected by every linter enabled in your project.
You can reproduce issues discovered in CI by running trunk check and addressing issues.
If trunk check continues to identify new Code Quality issues on your PR, first try merging the latest changes from your base branch. Trunk will rebase your changes on top of the current HEAD in main to ensure it catches all issues before merging.
If this continues to fail, then run git checkout refs/pull/<PR number>/merge && trunk check. This is a reference to the merge commit GitHub creates.
After initializing Trunk, you can begin scanning for issues in your repo, and decide whether to fix them up front, fix them incrementally as you code, or ignore irrelevant suggestions. This page walks through the process of linting locally and fixing existing issues.
If you only want to prevent new issues from new code changes, skip to Linting in CI.
After initializing Trunk Code Quality, you can run all tools on all files to look for existing issues. You can run Trunk on all files in your repo with this command. This will output all issues detected by every linter enabled in your project.
There are different approaches to dealing with existing issues, such as running format and applying automatic fixes, ignoring irrelevant issues, and sampling linters/files. This section walks you through the process to make fixing issues easier.
Some issues can be fixed automatically. You can apply fixes by running the following command.
You can also focus on the issues revealed by 1 linter at a time.
If that still produces too many issues, you can sample your files, such as 1/5 files.
You can drill down further and run only one single file.
Some recommended linters could be unnecessary for your project. You can disable and enable linters with these commands:
If there are warnings that don't apply to your project, you can ignore them by line, by file, or by class of warnings in each linter's config file.
You can tell Trunk Code Quality to ignore a line in your source code with a special comment like this:
Sometimes you may want to ignore entire files or groups of files, such as generated code. To ignore them, use the ignore key to your .trunk/trunk.yaml file:
You can also ignore an entire class of warnings using the config file of your linter, either at the project root or in .trunk/configs
For example, these are the ignores for Markdownlint in .trunk/configs/.markdownlint.yaml:
You can reproduce issues discovered in CI by running trunk check and addressing issues.
If trunk check continues to identify new Code Quality issues on your PR, first try merging the latest changes from your base branch. Trunk will rebase your changes on top of the current HEAD in main to ensure it catches all issues before merging.
If this continues to fail, then run git checkout refs/pull/<PR number>/merge && trunk check. This is a reference to the merge commit GitHub creates.
You don't need to fix all the issues. Trunk Code Quality has the ability to Hold The Line, which means it only lints your git diffs; only what you changed on your branch gets linted. The pre-existing issues can be managed later.
This allows you to clean up as you go, preventing new issues and letting your team leave each file with better code quality than before.
When you've fixed the existing issues you want to fix, you can skip to Linting in CI directly.
When you run trunk check without specifying --all, it will only run on files you've modified according to git. Remember to if you're using something other than main or master.
Learn more about .
If you're still overwhelmed by the results, you can fix them incrementally as you change files. See the section.
The comment should contain the name of the linter you want to ignore the following line, in this case clang-tidy For more complex ignore commands, see .