hide linter configs
complete
Sam Lijin
Trunk has a lot of great built-in configs that we suggest to users. Unfortunately, this still requires users to commit those configs into their repo at the root of the repo.
In theory, since trunk controls how linters are invoked, it's possible to push those config files into
.trunk
or instantiate with defaults.We've had two instances of users asking for this:
C
Chris Clearwater
complete
Eli Schleifer
Great thoughts here. I don't think hiding linter configs means we would obscure or re-invent the wheel - but some folks have asked for the ability for the option to host config files under .trunk.
We definitely are all about using the pre-existing paradigms vs. asking people to work without our thinking.
We won't make this a requirement. We have been discussing alternate ways for folks to more easily modify the command a linter executes vs. the rest of the config (which currently you need to replicate completely and edit vs replace a single line like 'run:'
Jonathan Garbee
Eli Schleifer: If things like eslint's config path option are exposed... People can host their configs anywhere which includes in
.trunk
. Same with other tooling with said option (most do have it.) Very few things like ls-lint currently don't have that kind of argument configuration, but it is on the books for a future release whenever that happens.Eli Schleifer
Jonathan Garbee: That's an excellent point. For tools that allow for a --config parameter we could allow that to be set as an optional value in the enabled linter entry. That would allow folks to override that piece of the run command cleanly.
Jonathan Garbee
I'd like to see the ability to add extra configuration per-tool to the yaml file while keeping the tooling config separated.
For example, eslint config can be stored in any place and given via a CLI flag as Trailstrider mentioned.
/etc/eslintconfig.js
for example. This may have some imported content and fuller JS logic happening to construct the configuration that is exported. Simply allowing config to be shoved into one internal file that is yaml has some serious drawbacks.1) Said config is then vendor-locked into Trunk. Good for Trunk, but off-putting to people who want isolated configurations per tool for easier understanding and portability.
2) No more dynamic construction, meaning it can be far more tedious to manage a complex configuration.
3) It may go against pre-existing team/company practices to keep configurations in certain locations.
4) Why re-invent the wheel when you can just add a layer on top of what the tooling already provides? Seems like a lot of effort in something that is already done for you with a config flag.
Benjamin Lupton
Ideally, I'd like to just inherit sensible defaults, then do any manual overrides inside the trunk.yml file. Ignoring specific linters on specific files is already supported, and something I already use: https://github.com/bevry/dorothy/blob/master/.trunk/trunk.yaml — so the ability to ignore specific rules, across the whole project or even on specific files would be a great addition to the trunk.yml configuration file.
Trailstrider
Benjamin Lupton: I like the sensible defaults and overrides approach. Most linters allow for CLI passing of configuration as well, instead of relying on a specific config file being in a specific place.