| Reporter |
Maarten Balliauw (Maarten.Balliauw)
|
|---|---|
| Created | Apr 26, 2018 3:32:02 PM |
| Updated | Apr 26, 2018 3:32:02 PM |
| Subsystem | No Subsystem |
| Assignee | Unassigned |
| Priority | Normal |
| State | Submitted |
| Type | Unspecified |
| Fix version | No Fix versions |
| Affected versions | No Affected versions |
| Fixed In Version ReSharper | Undefined |
| VsVersion | All Versions |
From https://youtrack.jetbrains.com/issue/IDEA-181641#comment=27-2842305
So, speaking for myself, I'd like:
- a "check" mode of running the formatter that:
- checks each file that it's targetted at (I don't need file-selection / globbing - single-file is fine for my use-case, where we'd shell out to this tool from another that handles file-selection/ignore/exclude)
- outputs a list of not-automatically-fixable violations (ideally on stderr, since it's probably not structured data)
outputs a diff that could be applied to fix automatically-fixable violations (ideally on stdout, since it's structured data) - gives an exit code that indicates what happened
- 0 = ran, successfully, no violations of any kind found
- -1 = ran, but some error occurred that makes results inconclusive (e.g. could not open specified file, permissions, things like that)
- 1 = ran, successfully, violations were found that are auto-fixable, here's the diff
- 2 = ran, successfully, violations were found that are not auto-fixable, here's the list
- 4 = ran, successfully, violations were found where some are auto-fixable (and here's the diff), and some are not auto-fixable (and here's the list)
- crucially - does not do anything other than read the file(s) being processed. Doesn't update their modification times, doesn't write to them in any way
- a "fix" mode of running that:
- does all of the above and in the same way, but here, auto-applies any changes that are automatically-fixable, overwriting files with the fixes in place
My use-case for "check" is to run in continuous integration, to guard against files being introduced that have issues that I've configured the tool to flag up. I don't want check to modify any files on disk / in-repo at all.
My use-case for "fix" is to run on a workstation, to speed up the workflow of realising there are fixes that need to be done, and applying all the ones that are automatically-fixable. I don't want fix to write any files that don't need any fixes applying.
re: file-selection and why we don't need it: We have a tool that we use for our local workflow (which we intend to open-source) which wraps various linters. It selects files to lint based on patterns (e.g. file extensions) to denote the language, since different linters apply to different languages. We filter that list so that things that are gitignore'd are removed. We filter that list so that vendored and generated code are removed. We then, optionally, figure out the list of files that have been changed since the feature-branch was created from the common origin branch - that's the list of files we want to actually lint, of the set of candidates. This means that we incrementally fix lint - it's fine for files in source control to be dirty, but the first touch to them means they need to be good-boy-scout fixed. This means we can incrementally add linters to our codebase and see it clean up over time.