Expose hermetic tools to shell
There are a handful of solutions out there for creating hermetic development evironments - docker, bazel, devenv.sh , asdf, nvm and others. With Trunk's ability to declare your environment for the purposes of linting and formatting, it doesn't feel like much of a stretch to allow engineers to utilize those same tools for other development tasks and to use trunk's config as the source of truth for a project instead of having to declare versions in multiple tools. I would love the ability to add the current repository's toolchains to my PATH or have them be exposed through a CLI command like trunk exec ... .
threshold medium doesn't suppress shellcheck errors
My trunk.yaml has: lint: threshold: - linters: [shellcheck] level: medium But if I have only low threshold shellcheck issues, trunk check still exits with status code 1 - so the github action fails. Is there some other config required to enable the threshold to work?
hijacking hooks broke my git
After installing trunk , git rebase would hang forever: $ GIT_TRACE=2 git rebase -i other-branch 13:36:42.905813 git.c:460 trace: built-in: git rebase -i other-branch 13:36:42.950107 run-command.c:1524 run_processes_parallel: preparing to run up to 1 tasks 13:36:42.950145 run-command.c:655 trace: run_command: /Users/Ross/.cache/trunk/repos/bcdba96019adf8e197586aa7271276fc/git-hooks/pre-rebase this-branch Even if I remove trunk's hooks, trunk replaces it when I run trunk check .
Support cascading overrides for config files
At the moment, if you want to override the default config file for an analyzer, you replace the default. This works but if Trunk decides to change the defaults for an analyzer in the future, those changes aren't propagated to the user. It would be nice to have a cascading override of the config files so that the Trunk default config is always applied first and then the user config file is applied on top of the default config file.
Support JSON schema validation for YAML/TOML
YAML and TOML are very commonly used for configuration files nowadays. However, the problem arises in the fact that many of these files have what can be considered their own languages specific to what they are configuring (GitHub Actions for example). Because of this, the standard of using JSON schemas for validating YAML/TOML files has gained a lot of adoption ( trunk has its own schema file as well). Red Hat for example has a very popular VSCode extension for YAML that allows users to identify what schema file is related to a certain YAML file and then provides edit-time validation, node outlining, IntelliSense, and node descriptions. The JSON schema standard's website has useful information regarding what tools are available for YAML and TOML validation (as well as others) and I believe this would be fairly straight forward to integrate and help everybody using these kinds of config files (most people at this point).
Code Coverage in Trunk UI
It would be amazing to see support to submit, visualize, track and gate on code coverage via turnk. Right now i still have to use a mix of similar tools where all local and PR linting/formatting is done by trunk, but code coverage is tracked/gated by other tools.
Code sync linter
Sometimes there are pieces of code that need to stay in sync (e.g. modifying an enum means modifying the function that handles them). It would be awesome to have a linter that looks for comment directives to trigger this kind of check. Even if it just requires both files to be modified would be nice, but even better would be if it could actually apply regex patterns to suggest fixes.