Run only specific linters on new files (similar to `new: true`)

Question

Run only specific linters on new files (similar to `new: true`)

qdm12 opened this issue 10 months ago · 3 comments

Welcome

Yes, I've searched similar issues on GitHub and didn't find any.
I agree to follow this project's Code of Conduct

Your feature request related to a problem? Please describe

I would like to run a linter, in my case goheader, only on modified/created (aka unstaged/untracked) files, but I still want to run the other linters on all files.

Describe the solution you'd like

The new: true option could take a list of linters i.e. new: ["goheader"]. If one sets this, it seems implied new: false to be set by default for other linters.

Describe alternatives you've considered

Have new as an object of true/false values for each linter, maybe with a default key too:
```
new:
  default: false
  goheader: true
```
Add another option new-linters which would be the inverse of the new value. So if new is false, linters specified in new-linters would run on new files.

Additional context

There is similar issue I opened golangci/golangci-lint-action#1140 which is closer to what I need (lint git diffs in a pull request), but I'll leave this opened since it would also be useful locally.

Supporter

I am a sponsor through GitHub or OpenCollective

Answer 1 · 2025-01-03T11:27:03.000Z

Your proposal requires running golangci-lint 2 times.

You can already do what you want with the following commands:

golangci-lint --new --enable-only goheader

Inside your configuration file, you must define the goheader configuration but not enable the linter.

Answer 2 · 2025-01-03T11:45:46.000Z

That does it indeed, but less ideal to run really because of the 2 commands, a config option would still be better, that's a bit why there would be a config file 🤔

Answer 3 · 2025-01-04T08:51:52.000Z

That does it indeed, but less ideal to run really because of the 2 commands, a config option would still be better, that's a bit why there would be a config file 🤔

I faced this once. I managed to solve my need by using (and .maintain) two configuration files. And launch then separately and sequentially if needed.

I don't think configuration should/could evolve in the direction of having support of "when I'm using new, I want this". First because it would be too complex, then because everyone needs is different, the need to add new things would be endless.

So my suggestion here is if you have different needs use different config files and use --config

This integrates pretty well in a CI workflow