Feature request: lint all files if .editorconfig changes

[thejuan]

If a change is made to .editorconfig provide an option to lint all files, not just changed files.

[bkoelman]

That sounds like a scenario where you'd just want to run dotnet jb cleanupcode instead of using Regitlint.

Style settings can be in .editorconfig files (at the repository and/or solution root, with possibly nested directories overriding parent settings) or they could be in *.DotSettings files (named after the project or solution, with similar overrides in nested directories, or cross-linked in the .DotSettings file itself using imports). It gets pretty complicated to make Regitlint determine when "settings have changed", so to me it sounds this is best solved as a manual step (assuming this doesn't happen that often), or possibly automated in your cibuild by git-checking which files have changed and choosing to run ReGitLint or dotnet command directly.

[thejuan]

The use case is a CI/CD check, to ensure if you make settings changes, everything has been formatted to match the new settings.

At the moment, I have to test for changes to .editorconfig with git diff and branch the script if it has changed, calling dotnet jb cleanupcode directly, otherwise calling regitlint.

It's definitely a nice to have, but I think of ReGitLint as providing all the interaction with git required to run dotnet jb cleanupcode. Allowing a one line command call to lint in CI/CD

[thejuan]

Understand the problems for people not using .editorconfig solely, so maybe not a good fit for the tool

[bkoelman]

In my experience, there's usually additional scripting needed. Examples here and here. Actually the story is worse. Resharper can be combined with StyleCop, which has its own config file and potentially affects formatting rules. The same applies to MSBuild variables in .csproj files or .props/.target files (example here). If you're using Rider and Resharper within the same team, additional Rider settings are needed to bring them in sync, example here.

The way I see it, ReGitLint is a simple tool for a simple job: execute an external cleanup tool, just passing it the set of changed files that git reports. ReGitLint is agnostic about how/where that cleanup process is configured. The advantage of that is that it doesn't need to be kept up-to-date when those things change.

@sethreno Thoughts?