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

Add a rubocop-rails ruleset #266

Open
searls opened this issue Mar 4, 2021 · 8 comments
Open

Add a rubocop-rails ruleset #266

searls opened this issue Mar 4, 2021 · 8 comments
Labels
enhancement ✨ New feature or request

Comments

@searls
Copy link
Contributor

searls commented Mar 4, 2021

[rubocop-rails(https://github.com/rubocop/rubocop-rails) has come a long way since we started the Standard project, and there's a lot in it that I think Standard could benefit from.

My approach to integrating it would look a lot like how we incorporate rubocop-performance, currently. However, there are a couple wrinkles:

  1. rubocop-rails has a hard dep on activesupport, which means if we add it as a hard dep on standard, people avoiding Rails-related gems in their project would get it whether they want it or not and —though it's >=—could create transitive pain for some users. We should investigate ways of enabling it without adding it as a hard runtime dep for all users all the time.
  2. We should inspect what rubocop-rails already does to detect Rails apps vs. non-Rails projects, and (since Standard is all about defaults), we should do our best to intelligently only lint when we're sure we're in a Rails app.
  3. I suspect whatever we do in (2) will not be perfect, so we probably need a config flag for rails: true/false

Thoughts?

@searls searls added the enhancement ✨ New feature or request label Mar 4, 2021
@taylorthurlow
Copy link

If there's one thing I learned using rubocop-rails it's that it's not all that great at determining what is or isn't a Rails app.

It's not awful at it, and I'm sure it will be helpful, but don't look to it as a goal.

@searls
Copy link
Contributor Author

searls commented Mar 5, 2021

Thanks for the advice

@mrcasals
Copy link

mrcasals commented Mar 8, 2021

Maybe for standard maintainers it's easier to have a standard-rails gem? It could use standard as a dependency, and add rubocop-rails.

This way from a standard perspective you wouldn't need to care about Rails apps, and from standard-rails you can assume it's being used in a Rails app.

@diesl
Copy link

diesl commented Sep 12, 2022

Hi @searls,

unfortunately, this issue has not seen any activity since almost one year. I wonder if you have plans for adding this in the near future?

I am really looking forward to have a rails ruleset integrated. They way @mrcasals proposed seems like a good idea. What do you think?

@searls
Copy link
Contributor Author

searls commented Sep 12, 2022

I think that this is the right architectural perspective, but after discussing with a lot of users of rubocop-rails, I've not found very many endorsements that it would be worthwhile (put differently, I haven't seen much evidence that an opinionated, fixed ruleset could be chosen and meet our expectations for universality, consistency, and reasonability).

I'll take a second look

@diesl
Copy link

diesl commented Sep 13, 2022

Thank you for your quick anwer and explanation.

I think it would still be worthwile to have an opinionated ruleset, even if it does not meet the high standards in the beginning, compared to having no ruleset at all.

One of the big advantages still is not having to argue about rules if there is one standard 👍

@xdmx
Copy link

xdmx commented Feb 10, 2023

I can't wait to start using standard-rails and others given the recent update 🙌

@searls
Copy link
Contributor Author

searls commented Feb 10, 2023

@xdmx stay tuned! Should have something to share in the next couple months

@searls searls removed this from Backlog in Test Double Trouble Apr 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ✨ New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants