Solargraph: supporting rubocop's --force-exclusion option

[jonknapp]

Rubocop has an option called --force-exclusion that will ignore any linter errors for files that a user's configuration has explicitly ignored. I'm not quite sure why it's not the default, but that's another story 😄 . I imagine someone _may_ enjoy being able to lint a file their config excludes for some reason.

I would either like to update the default Rubocop config to add the --force-exclusion flag or add a way to specify it through an extension setting and/or .solargraph config file. My two cents are to set it as a default configuration option so that adding another dot file to a project is a requirement to run rubocop with that project's config.

---

I wanted to start the conversation as an issue but I'm more than willing to create some additional tests and a PR to add the support if desired.

[castwide]

RuboCop assumes that if the file was passed as an explicit argument, as Solargraph does, the user expects it to be linted, regardless of the exclusion settings. I can see how that's not always the case, though. I'm open to a PR for this.

[jonknapp]

Do you have a preference on "default" argument vs VS Code config vs solargraph config vs something else?

I would assume it depends if users of solargraph, rubocop, and/or a solargraph consumer (like the VS Code plugin) would use both versions of the flag and under what circumstances.

[castwide]

I'm tempted to say --force-exclusion should not be the default. I'd prefer to get diagnostics for any file that I open in an editor, while the exclusion rules should apply when you're linting the entire workspace.

The .solargraph.yml file seems like a reasonable place for the option, since that's where the reporters are configured. I'm not sure what the convention should be, though. Maybe it could look something like this:

reporters:
- rubocop:
  - force-exclusion

If it's an option in both .solargraph.yml and the VS Code settings, I'd expect to the VS Code setting to take precedence.

[jonknapp]

Yea, I tend to lean towards not making it the default as well.

Maybe a way to pass cli options with a single yaml config line? I'm not sure if there's a desire to tweak other things as well, but I've seen other libs take that approach. Something like:

reporters:
- rubocop:
  additional_cli_options: "--force-exclusion"

It would future proof things a bit at least. Not a fan of my long option name though.

[castwide]

That could work. For a shorter name, we could call it arguments.

[jonknapp]

I like that. If you don't mind, I'll probably add it to both this project and the vs code extension so I don't have to add a .solargraph config to each project I want to use the different linter rules in.

Thanks for the gem and extension!

[jonknapp]

Before I continue the deep dive into a VSCode addition, I'd like to talk through it so I know if it's a direction you'd like to support @castwide. Feel free to say "no" or offer up an alternative you think would work better.

1. Update the VSCode plugin to take a new configuration (solargraph.diagnostics.rubocop.force_exclusion) that is false by default. It's a long key but it's explicit.
2. Update the solargraph-utils plugin to accept the new configuration argument and pass it along to solargraph. Possibly only do this if the gem supports it?
3. Update solargraph to take the new host configuration object and ignore the value in .solargraph if --force-exclusion is found in arguments

[castwide]

You shouldn't need to update solargraph-utils. Client configurations get passed to the server via the LSP initialize and workspace/didChangeConfiguration methods. You can access them as a hash via LanguageServer::Host#options. Everything else looks solid.

[jonknapp]

Cool, thanks for the heads up @castwide. I may work through these changes at a slightly slower pace but am still interested in contributing them. If your thoughts on approach change at all, feel free to let me know.

[jonknapp]

I just found out that Rubocop options can be passed along in a file called .rubocop with the following contents:

which also appears to work with the ruby Rubocop interface you are interacting with through Solargraph. That means, my original itch could be scratched by adding that file to my projects and not having to pass more options through solargraph and/or VS code extensions.

I'm still game to add the functionality when I get time to focus on it, but wanted to make you aware just in case this was functionality you'd rather not have in solargraph.

[castwide]

Good catch. I would definitely encourage using a .rubocop file, just to keep a direct association between configuration settings and the software they affect.

Are there cases where it would be more practical to configure RuboCop through Solargraph instead? I haven't run into that issue myself, but I can imagine situations where, e.g., you want diagnostics in your editor to behave differently from a lint reporting tool.

[jonknapp]

Yea, I'm not too sure. I can't think of a use case besides trying to alter defaults provided by Solargraph which isn't needed if there are docs about how to handle different situations. That said, there may be users trying to get specific info from Solargraph that configuration would aid.

[castwide]

Fair enough. Cases where these options are necessary seem uncommon but not impossible. They're also isolated enough that they shouldn't get in most users' way. As long as the default behavior is to use the local RuboCop configuration, it should be fine.

I'll leave it up to you. If you figure they're worth finishing, I'll merge them into the gem and extension.

[landonepps]

I just found out that Rubocop options can be passed along in a file called .rubocop with the following contents:

This worked for me! I was tired of rubocop complaining about Rails' autogenerated files.
For the record, this file goes in your project's root directory not your home directory.