feat:resharper

[xentropic-dev]

Implements support for JetBrains resharper code inspection CLI tools.
Closes #798

[mfussenegger]

Is this the official name? E.g. in the AUR package there is a inspectcode command. In the upstream .zip there are inspectcode.exe and inspectcode.sh. No jb.

It is also a bit strange to me that this doesn't support writing the output to either stdout or stderr like every other linter. Or that it can't discover the solution file by itself.

Maybe worth making some upstream PRs first to get this into a shape that makes it easier to integrate.

(And the PR can also be adapted to use the for_sarif parser function.

[xentropic-dev]

Good question. I think the way most people install it is via Jetbrains suggested method here: https://www.jetbrains.com/help/resharper/ReSharper_Command_Line_Tools.html#install-and-use-resharper-command-line-tools-as-net-core-tools

If installed this way using dotnet tool, the command is indeed jb.

dotnet tool install -g JetBrains.ReSharper.GlobalTools

jb inspectcode YourSolution.sln -o=<PathToOutputFile>

I didn't know the for_sarif parser function was merged. I'll use that.

When you say upstream PRs, do you mean something like Mason so we can have standard way to install?

I also found it really weird that stdout wasn't an option and it also made this kind of a pain to implement. I'll revisit that and make sure 100% that it doesn't support stdout. When you call it without the -o option, it tells you to specify an output file, but I might be missing something.

[xentropic-dev]

Btw, I'm really not sure the point of the AUR. I use arch as well and managing the package via dotnet tool works great. Not sure what circumstance people are in where they want to use Resharper without dotnet. I'm sure there's a reason.

[mfussenegger]

When you say upstream PRs, do you mean something like Mason so we can have standard way to install?

No, I mean upstream to the resharper command line tools project. If -o isn't optional it probably should be.

Btw, I'm really not sure the point of the AUR. I use arch as well and managing the package via dotnet tool works great.

My point is that if there is not yet an established name for the tool, the linter here won't work for a lot of people.

[xentropic-dev]

I got it. I just think you stumbled upon an AUR that probably isn't widely used. The normal way to install is with dotnet tool

[xentropic-dev]

And you cannot contribute to the resharper project. It is closed source.

[xentropic-dev]

@mfussenegger I left a comment on the AUR package asking what scenario somebody would use and will let you know what I find out. The package has a popularity of 0 and has 0 votes which really aligns with my suspicion that you have found an unconventional way to install the Resharper CLI; I think is giving you doubts about how universal the jb command is.

I'm thinking about this issue and have a couple of ideas that can help clear the confusion.

• Many people manage their lsp/linting dependencies through Mason. Perhaps I can do a PR there to help prevent people from installing Resharper through an unconventional way.
• I could create a jb shell script for the AUR package that would make it compatible with this PR. I think there is a very low risk of somebody using this AUR and nvim-lint together, but I'll leave that up to you and will attempt to contribute to the AUR as a workaround.
• Do we have a precedent for anything like this in the repo already, where it might warrant adding some documentation specific to the linter in this repo itself? A simple note somewhere saying, this feature requires installing Resharper with dotnet tools, and perhaps a link to the official install instructions by Jetbrains?

Regarding the stdout issue, the only solution I can find, and I am open to other suggestions, is to create a wrapper around the Jetbrains tool and saves the output to a file and then pipes the file to stdout. That solution doesn't seem any better than the current solution though, which involves letting the plugin to manage a temporary file for the Resharper report output.

I've also opened an issue with Jetbrains: RSRP-500996 jb inspectcode to stdout

Another option would be to use in-memory files, which I think would make this feature OS specific. In terms of in-memory files, I only have experience with named pipes on windows, but it looks like it would be possible to set the output of the plugin to an in-memory file based on the OS. Let me know if you'd like me to explore this option.

Resharper is a very weird tool because it is best implemented in Rider, Jetbrains IDE. I see that many C# developers are migrating away from Visual Studio to other IDEs or code editors. Some small percentage of us are polyglot programmers and would rather use a code editor like VS Code or Neovim. It would be great to provide these niche programmers with some of the enterprise-level tooling they expect from their IDEs. But maybe Resharper is too weird of a linter to include in nvim-lint and warrants a plugin of its own. I actually think I could probably provide a better experience for the user as a plugin, because I think I could optimize it to run a little faster by pre-loading the diagnostics for the entire solution in the background so that the diagnostics are already available when the file is opened, then just lint the difs as the code is edited.

I'm fine with any approach, just let me know what you need from me.

[mfussenegger]

Okay based on the AUR conversation there are actually two different tools, so going with jb is fine.

But I'd still like to see https://youtrack.jetbrains.com/issue/RSRP-500996 happen before getting this in. Of the ~150 linters included in nvim-lint, this would otherwise be the only one requiring a tempfile.

I also wonder if this should be called simply jb instead of resharper to match the executable?

[xentropic-dev]

But I'd still like to see https://youtrack.jetbrains.com/issue/RSRP-500996 happen before getting this in. Of the ~150 linters included in nvim-lint, this would otherwise be the only one requiring a tempfile.

Makes sense. I'll keep track of the ticket and bump it if I don't see anything.

I also wonder if this should be called simply jb instead of resharper to match the executable?

I can get behind this, especially since there are technically some subtle differences between the Resharper plugin and the Resharper command line tools (jb inspectcode).

Thanks!

[xentropic-dev]

JetBrains updated the ticket stating that this will be available in the next release 2025.3. Thanks for keeping this ticket open. I intend to close this loop when 2025.3 is released.