Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out what to do with rbi.yaml #2

Open
searls opened this issue Jun 30, 2023 · 2 comments
Open

Figure out what to do with rbi.yaml #2

searls opened this issue Jun 30, 2023 · 2 comments

Comments

@searls
Copy link
Contributor

searls commented Jun 30, 2023

rubocop-sorbet ships with this config for rbi files and I'm unsure what to do about it.

We can't just merge it into the config for RBI files b/c it reconfigures a bunch of base rubocop rules (which is disallowed by Standard).

The one idea I have is for a plugin setting like this:

plugins:
  - standard-sorbet:
      ignore_unnecessary_rules_for_rbi_files: true

And then given that configuration, add in a nested ignore somehow (off the top of my head I'm not sure this would work), similar to how you can ignore rules for entire globs in standard.yml

ignore:
  - '*.rbi':
    - Layout/AlignHash
    # … etc etc

Unsure what else might make sense or be workable

@maxveldink
Copy link
Contributor

Is there a way to "boot" Rubocop with a different configuration that only targets *.rbi files? That way, we could have two different rulesets configured and enforce a standard, non-configurable set of rules specifically for RBI files.

We normally ignore linting on RBI files in our Rubocop configs, so I admit I haven't thought too much about how they should be linted/formatted.

@searls
Copy link
Contributor Author

searls commented Jul 14, 2023

That is possible but I'm not sure it's worth it.

I think the right solution is an ignore glob that effectively disables the same rules as that rbi config file, but a plugin can't provide that (and I'm not sure it should, since in this case we'd be disabling rules that are owned by other standard plugins). Flip side is that it'd be a lot to paste into every .standard.yml file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants