houseabsolute / precious

One code quality tool to rule them all
Apache License 2.0
82 stars 4 forks source link

Use labels to support applying different subsets of configured tools #8

Closed autarch closed 1 year ago

autarch commented 3 years ago

A good example of this is that it might make sense to configure things differently for pre-commit hooks versus for a CI run.

With golangci-lint, if you have a large codebase, running it simply on the root of the repo can take a long time, so it's better to run it on per-directory basis in that case. But if you want to run it on the entire codebase in CI, it's much faster to run it as golangci-lint run . than to run it on each directory separately.

Another use case would be to separate out commands that make changes we always want (basic tidiers) from more aggressive things like running clippy with its --fix flag.

A good config key for this is probably labels. This would be an array so a give command could be assigned multiple labels. If no labels are assigned, it would default to a one-element array, [ "default" ]. If no labels are given on the CLI, that would be the label used. If a command had labels specified, then default would have to be added explicitly.

A more complex version of this would be to use a map of labels to args so you could configure a command once, but change the args it gets based on a label. This would allow configuring things like golangci-lint once, so it could be used a tidier and linter, but then be run with --fix given a specific label.

But that would make the config awfully complex. It's probably best to start with just requiring a duplication of the command with different args and labels.

autarch commented 1 year ago

Done in v0.5.1