sethreno / regitlint Goto Github PK

Hi,
On line 330 in Cleanup.cs you check if the tool is installed locally.

For some Teams it is a matter of dispute on whether or not you want to run Resharper in Visual Studio or only through commandline. In those cases it would be helpful if ReGitLint could fall back to use the Globally installed (dotnet tool install -g) version of Resharper jb tool. That way you don't need to explicitly install the tool manifest in every repo as well.

Hi and thank you for this great tool. I've made a custom codecleanup profile and I try to use it with the parameter --jb --profile=custom_profile.

Unfortunately the cli is ignoring the parameter and uses the Built In config. Is it a bug, or am I doing something wrong?

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

Hi @sethreno,

Thanks for addressing open bugs. I'd like to upgrade to the latest version, but have some concerns.

• You're targeting .NET 6 now. I suspect that now it has to be installed on build servers to use it, but we're not there yet. This is a huge breaking change, as the previous minor version worked on .NET 3.1 and .NET 5.
• The fix for #10 now matches too much in all cases. Our VMs on build server are slow already, this makes things worse for everyone. It would be nice to put the wider matching behind a command-line switch, so only users with their .sln in a subfolder can activate this.

Had to wrap ReGitLint in a powershell script to get it to behave well on the build server. It would be nice if it just did all of this automatically.

    if ($jenkins) {
        $commitA = $env:GIT_PREVIOUS_SUCCESSFUL_COMMIT;
        $commitB = $env:GIT_COMMIT;

        if ([string]::IsNullOrEmpty($commitA)) {
            $commitA = $commitB;
        }

        write-host "commit-a $commitA"
        write-host "commit-b $commitB"

        ../packages/ReGitLint.1.5.2/tools/ReGitLint.exe `
            -s ../ot.sln -f commits `
            --commit-a $commitA `
            --commit-b $commitB `
            --fail-on-diff

        if (!$?) {
            write-host "format producted the following diff:";
            git diff
            exit 1;
        }
    }

Maybe I haven't understood correctly all instructions, but it seems there is no support for providing a code cleanup profile to apply.

I've currently used these one-time commands to globally perform code cleanup with the JetBrains donet jb codecleanup global tool:

# install dotnet global tool if missing
dotnet tool install -g JetBrains.ReSharper.GlobalTools

# see code cleanup syntax
jb cleanupcode --help

$slnDir = "C:\Development\repo\SolutionFolder"
$slnFile = "SolutionFileName.sln"
$codeCleanupProfileName = "ProfileName"

cd $slnDir

# run code cleanup
jb cleanupcode --profile=$codeCleanupProfileName --include="SubFolder/**/*.cs" --exclude="**/*.designer.*;**/Migrations/**/*.cs" $slnFile

I'd love to setup a pre-commit hook to share with my team, and ReGitLint seems pretty useful to that goal, but I would need it to support specifying a code cleanup profile name.

Hi!

I have the following folder structure:

• sln_folder/MySolution.sln
• sln_folder/TestClass.cs

dotnet regitlint -f staged and dotnet regitlint -f modified don't work for this folder structure.
And it doesn't matter if I run the tool from the root or from the sln_folder folder.

Files in --include option (used --print-command option) always have absolute path from the root, but it should be relative to the solution.

I would appreciate it if you can fix this issue.
Thanks.

Package Id                           Version         Commands
------------------------------------------------------------------
jetbrains.resharper.globaltools      2021.3.2        jb
regitlint                            6.0.6           regitlint

I have a powershell script set up in order to call the regitlint command, but when doing so with a profile name specified, the cleanup command will throw an error:

VERBOSE: dotnet regitlint -s ".\My.sln" -f staged -p "**/*.cs" --print-command --jb --profile="Built-in: Reformat & Apply Syntax Style" --jb --verbosity="WARN"
JetBrains Cleanup Code 2021.3.2
Running on AMD 64 in 64-bit mode, .NET Core 3.1.19 under Microsoft Windows 10.0.19043
Version: 2021.3.2
dotnet tool run jb cleanupcode ".\My.sln"  --profile=Built-in: Reformat & Apply Syntax Style --verbosity=WARN -dsl=GlobalAll -dsl=GlobalPerProduct -dsl=SolutionPersonal -dsl=ProjectPersonal
JetBrains Cleanup Code 2021.3.2
Running on AMD 64 in 64-bit mode, .NET Core 3.1.19 under Microsoft Windows 10.0.19043
Usage: cleanupcode [options] [solution or project file]
Show help: cleanupcode --help

However, when I leave off the profile entirely, I can see that regitlint is escaping the built-in profile that it uses:

VERBOSE: dotnet regitlint -s ".\My.sln" -f staged -p "**/*.cs" --print-command  --jb --verbosity="WARN"
JetBrains Cleanup Code 2021.3.2
Running on AMD 64 in 64-bit mode, .NET Core 3.1.19 under Microsoft Windows 10.0.19043
Version: 2021.3.2
dotnet tool run jb cleanupcode ".\My.sln"  --verbosity=WARN --profile="Built-in: Full Cleanup" -dsl=GlobalAll -dsl=GlobalPerProduct -dsl=SolutionPersonal -dsl=ProjectPersonal
JetBrains Cleanup Code 2021.3.2
Running on AMD 64 in 64-bit mode, .NET Core 3.1.19 under Microsoft Windows 10.0.19043

I have tried various manners of escaping this in my powershell script, but none seem to work.

I think it would make sense for regitlint to escape this parameter on the C# side, instead of requiring callers to always escape it (since it is pretty expected for the profile names to contain spaces, given that the built-in resharper ones use spaces)

Sorry, I know this issue is not related to ReGitLint, but I am quite desperate and I believe you could know the solution. Do you know if there is a way of skipping build on jb cleanupcode? The build is taking too much time and I would like to skip it.

Thank you!

#20
Reproduced in dotnet sdk 6.0.400 version

In my project, there are something library created by myself, how to disable the formatter with using System; or using System.Web.Routing; or others ? My project has a lot of folders and files, please provide the command line methods to help me to handle this issues.

When using the -f modified flag, this translates to the next command:

git diff --name-only

which lists modified and deleted files, but does not include newly added files. I found that the next command does list all three types:

git ls-files --others --exclude-standard --modified

Is it possible to use ReGitLint in a way to auto-commit formatted file?
I'm currently using this in my pre-commit hook:
dotnet regitlint -f staged --format-only

But all it does when executing is commiting the unformated files. The format fixes are applied to the files, but then I have to save all modified files manually to make them appear as unstaged changes. Is there a way to format all files, save the changes, stage the changed made by ReGitLint and commit them using only one commit?

We would like to start gradually rolling out ReGitLint, first to run it against some autogenerated code, then only later against the entire (large) solution.
From the documentation, I cannot see a way to run the tool with a .csproj file, only with -s <solution.sln>. It also appears that running it with the -p "./only-here" flag won't respect a relative path when run from the directory in which the project resides.

Is there a way to let ReGitLint only touch files of a specific directory or C# project?

Can we add the jb no-build flag to this?
--no-build : Do not build solution before processing (default: False).
from jb cleanupcode --help

Today cleanup can be run on either staged files (-f staged), modified files in the working tree (-f modified), the set of changed files in a single commit (-a 3796556), or the set of changed files between two commits (-a 6708090 -b 3796556).

I would like to be able to run against the set of changed files in one or more commits, plus the set of staged and the set of unstaged files.

This speeds up local development, compared to running a full cleanup. I would pass the commit hash of the base branch and HEAD, so that it reformats all files in those commits plus the files (staged/unstaged) that I'm still working on.

Currently have to build multi-runtime images to use reglint

The following code at https://github.com/sethreno/ReGitLint/blob/master/ReGitLint/Cleanup.cs#L327-L333:

            if (!jbArgs.Contains("-dsl")
                && !jbArgs.Contains("--disable-settings-layers")) {
                // ignore settings that might conflict with .editorconfig
                jbArgs.Add("-dsl=GlobalAll");
                jbArgs.Add("-dsl=SolutionPersonal");
                jbArgs.Add("-dsl=ProjectPersonal");
            }

does not clear all machine-wide and personal settings layers. See json-api-dotnet/JsonApiDotNetCore#1104 for details. It appears that -dsl=GlobalPerProduct is missing in this list (see https://www.jetbrains.com/help/resharper/CleanupCode.html).

Edit: removed suggestion to use --no-buildin-settings, because it does achieve the desired effect.

It seems like there was a breaking change in the dotnet sdk 6.0 making ReGitLint unusable.
When trying to format staged files the following output ist displayed using the sdk version 6.0.201:

PS C:\c\grow3d> dotnet regitlint -f staged --fail-on-diff --format-only
No sln file specified. Searching for one...
Found .\backend\backend.sln. Using that.
error:command "cleanupcode" not found
error:argument"-v" not found
looks like jb dotnet tool isn't installed...
you can install it by running the following command:

dotnet tool install JetBrains.ReSharper.GlobalTools

Upon further investigation I found that you use "dotnet tool run jb cleanupcode" to run the Resharper.
This has changed to "dotnet jb cleanupcode" in the sdk 6.x.

using this global.json at the project's root fixed the issue for me:
{ "sdk": { "version": "5.0.406" } }

However in the future it would be nice to have an updated release that checks for the configured sdk version and using the appropriate syntax. :)

This will have a couple benefits:

• it'll make it easier to install
• ReGitLint will work cross platform

Found a crash (see here), resulting from this commit. Two causes I can think of:

1. The commit contains delete of the file ".github/CONTRIBUTING.MD" and add of the file ".github/CONTRIBUTING.md" (note the case change in file extension)
2. I did several forced pushes to the PR branch, so perhaps that made commit hashes invalid?

Note I'm using this script to run during cibuild.

Sorry for not providing clear repo steps this time, but I thought you'd like to know. Will report back if this happens more than once and I have more info.

I run

ReGitLint.exe format -s "PATH TO SLN.sln" -f Modified

but don't see CleanupCode making any changes.

JetBrains Cleanup Code 2020.1.3
Running in 64-bit mode, .NET runtime 4.0.30319.42000 under Microsoft Windows NT 6.2.9200.0
Usage: CleanupCode.exe [options] [project file]
Show help: CleanupCode.exe --help
PM> 

If I add -d to the end, it says...

!!!! Process Aborted !!!!
Code formatter changed the following files:
 * /Models/File.cs
PM> 

So I can see it knows what to change, it just never seems to alter the file.

Anything I'm missing?

Looking for something that satisfies the following command:

'dotnet regitlint -f commits -a head^ -b head -p "**/*.cs"

hello thank you for the great tool. perhaps i am misunderstood how it works.

i have a .editorconfig with a naming rule for private fields to be _camelCase naming style. but when i run this tool it does not fix these.

i made a sample project to illustrate:

sample project

Sample/
  Sample.sln
  .editorconfig
  .config/
    dotnet-tools.json
  Sample/
    Program.cs

Sample/Sample/Program.cs

public class Test
{
    private readonly string BadName = "test";

    public static void Main(string[] args)
    {
    }
}

Sample/.editorconfig

# editorconfig.org

# top-most EditorConfig file
root = true

# C# files
[*.cs]

# internal and private fields should be _camelCase
dotnet_naming_rule.camel_case_for_private_internal_fields.severity = error 
dotnet_naming_rule.camel_case_for_private_internal_fields.symbols  = private_internal_fields
dotnet_naming_rule.camel_case_for_private_internal_fields.style    = camel_case_underscore_style
dotnet_naming_symbols.private_internal_fields.applicable_kinds = field
dotnet_naming_symbols.private_internal_fields.applicable_accessibilities = private, internal
dotnet_naming_style.camel_case_underscore_style.required_prefix = _
dotnet_naming_style.camel_case_underscore_style.capitalization = camel_case

expected behavior

fixes the naming violation

dotnet regitlint

Sample/Sample/Program.cs

public class Test
{
    private readonly string _badName = "test";

    public static void Main(string[] args)
    {
    }
}

actual behavior

nothing changes. VS does detect the issue as does build

dotnet regitlint

Sample/Sample/Program.cs

public class Test
{
    private readonly string BadName = "test";

    public static void Main(string[] args)
    {
    }
}

what i have tried

1. using suggestion, warning and error for the severity
2. adding dotnet_naming_rule.camel_case_for_private_internal_fields.resharper_style = _aaBb according to resharper rules reference

any help or guidance appreciated. i have come across your tool as salvation for a very large codebase that has been neglected. trying to establish a coding style standard programmatically because going through by hand will take much too long.

When you use the --jenkins option regitlint returns non-zero and prints the diff showing the changes. Something like:

!!! Process Aborted !!!!
Code formatter changed the following files:
 * Core/Location.cs
 * Legacy/LegacySettingsDb.cs
diff --git a/Core/Location.cs b/Core/Location.cs
index eb0c8ce..97e7668 100644
--- a/Core/Location.cs
+++ b/Core/Location.cs
@@ -1,7 +1,7 @@
-using System;
+using Core.RateMethods.MinWage;
+using System;
 using System.Collections.Generic;
 using System.Linq;
-using Core.RateMethods.MinWage;
 
 namespace Core
 {
@@ -97,6 +97,8 @@ namespace Core
         public List<PayCycle> CorpPayCycles { get; set; } =
             new List<PayCycle>();
 
+        public string POSType { get; set; }
+

That's nice, but it would be even nicer if it would show you the command to run to fix the issue. Something like:

Runt the following command to fix the style issues:

dotnet regitlint -f commits -a 5774cc -b 754a25

When running in diff mode (-f switch with staged, modified and/or commits), multiple runs of cleanupcode are batched up. If the number of files is very high, resulting in many batch runs, it becomes more efficient to switch to running one full cleanup instead.

Use case here: A full cleanup takes about half an hour, but the batching (16 times) causes the cibuild to timeout after an hour.

I'm proposing to add a command-line switch to set that threshold, defaulting to 10 runs. With the built-in batch size of 7000, this would mean a full cleanup is run when the number of affected files is higher than 70,000.

Edit: on second thought, the switch should default to -1 (disabled) to avoid a breaking change.

When building a branch in jenkins for the first time the GIT_PREVIOUS_SUCCESSFUL_COMMIT environment variable is null. Current ReGitLint behavior for Jenkins is to set the AssumeHead option to true. This causes the list of files to be determined with the following git command:

git diff --name-only HEAD GIT_COMMIT

In the case of a first time branch build HEAD and GIT_COMMIT (the commit triggering the build) will be the same and the list of files will be empty.

This is bad because it often causes formatting issues to only show up after the branch is merged to master.

One option I'm considering to fix the issue is to modify the SetJenkinsOptions method to set CommitA to origin/HEAD if GIT_PREVIOUS_SUCCESSFUL_COMMIT is null.

Here's the current SetJenkinsOptions method for reference:

private void SetJenkinsOptions()
{
    FailOnDiff = true;
    PrintDiff = true;
    PrintFix = true;
    AssumeHead = true;
    FilesToFormat = FileMatch.Commits;
    CommitA = Environment.GetEnvironmentVariable(
        "GIT_PREVIOUS_SUCCESSFUL_COMMIT"
    );
    CommitB = Environment.GetEnvironmentVariable("GIT_COMMIT");
}

Alternatively I'm considered adding an AssumeOriginHead option instead that might work for non-jenkins build servers that face this same issue.

Hey guys, this is not really a bug report or feature request.
I just want to ask if you have performance issues with the jet brains tool.
I am using regitlint as a nice way to only scan the staged files. But the scan takes 2 minutes even if there is only 1 change file.
Did any of you face similar performance issues with the JetBrains tool?