-
Notifications
You must be signed in to change notification settings - Fork 115
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
Adding Rubocop Gems and Removing Rootstrap Rubocop #391
Conversation
.rubocop.yml
Outdated
- .rubocop-rs-config.yml | ||
- .rubocop-excludes.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just curious, but why do you like having these 2 files? don't you think that excluding cops is also part of the "rs config"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I know it's part of the rs config but I thought could be better if we have all the exclusions in a specific file because it is easier to visualize and you can see all the places where you are excluding a cop. In the other file, there are too many rules and information. But it was just my idea, if you don't like it I can remove it.
it 'returns the user' do | ||
it 'returns the user id' do | ||
expect(json[:user][:id]).to eq(user.id) | ||
end | ||
|
||
it 'returns the user email' do | ||
expect(json[:user][:email]).to eq(user.email) | ||
end | ||
|
||
it 'returns the user username' do | ||
expect(json[:user][:username]).to eq(user.username) | ||
end | ||
|
||
it 'returns the user uid' do | ||
expect(json[:user][:uid]).to eq(user.uid) | ||
end | ||
|
||
it 'returns the user provider' do | ||
expect(json[:user][:provider]).to eq('email') | ||
end | ||
|
||
it 'returns the user first name' do | ||
expect(json[:user][:first_name]).to eq(user.first_name) | ||
end | ||
|
||
it 'returns the user last name' do | ||
expect(json[:user][:last_name]).to eq(user.last_name) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe would be better to keep it as it was and add :aggregate_failures
?
https://docs.rubocop.org/rubocop-rspec/cops_rspec.html#aggregate_failures-true-default
@@ -1,3 +1,5 @@ | |||
# frozen_string_literal: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they are standardrb/standard#181 (comment)
expect(response).to be_successful | ||
end | ||
|
||
it 'returns no need to update' do | ||
subject | ||
endpoint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer keeping subject
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, at least for when we are just declaring it. We could also modify the ImplicitSubject
NamedSubject
cop. I do prefer naming the subject for most of other cases, but not sure if it's the best to enforce it always.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to change it because the NamedSubject cop. I don't have any preference about it, I would like to hear the opinion of @santib and @JulianPasquale
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also feel a bit strange naming the subject. Always felt subject
is descriptive enough.
That said, I don't have an strong opinion either. I'm actually ok disabling this cop, doesn't sound too critical
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion either 😅 whatever the team prefers. Or we can just go with Rubocop default, or check what is the preferred style by Standard.rb 🤷♂️
.rubocop-excludes.yml
Outdated
RSpec/VerifiedDoubleReference: | ||
Exclude: | ||
- spec/policies/admin/application_policy_spec.rb | ||
- spec/policies/admin/page_policy_spec.rb | ||
- spec/policies/application_policy_spec.rb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't it be better to fix them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea was to fix all of them in another PR, the main goal of this one was just to set the rubocop configuration and fix the ones that appear after setting it
.rubocop-excludes.yml
Outdated
@@ -0,0 +1,46 @@ | |||
Lint/AmbiguousBlockAssociation: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit worried to have apps start with so many exceptions.. it feels like we are encouraging people to do it lightly. No need to do it right now, but maybe we can tackle it in the future. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a deeper discussion about the cops and what do they enforce 🤓
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work! some questions
Is the idea of changing "subject" to "policy," "endpoint," etc., suggested by RuboCop, or is it a separate change?
Is it possible to move the RuboCop files to a folder, or do they have to be in the project's root directory?
.rubocop-excludes.yml
Outdated
@@ -0,0 +1,46 @@ | |||
Lint/AmbiguousBlockAssociation: | |||
Exclude: | |||
- spec/**/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is due to the change method, another option could be to add it in rs-config instead:
Lint/AmbiguousBlockAssociation:
AllowedMethods: change
Not sure if there's another similar case in tests.
expect(response).to be_successful | ||
end | ||
|
||
it 'returns no need to update' do | ||
subject | ||
endpoint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, at least for when we are just declaring it. We could also modify the ImplicitSubject
NamedSubject
cop. I do prefer naming the subject for most of other cases, but not sure if it's the best to enforce it always.
About the first point, It is because the NamedSubject cop, which forces you to name your subjects. |
AllCops: | ||
NewCops: enable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using this config, new cops ("pending" cops) will be enabled when we upgrade the gem. The other option would be to use disable
and manually enable the new ones.
https://docs.rubocop.org/rubocop/versioning.html#pending-cops
I'm ok keeping it as enable
. I think that will help us to be aware of the new cops and understand them in a better way so we can decide if we really want it or not.
I would also like to hear the group opinion here 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm good with the enable option, especially since it's a base app
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥
@@ -30,7 +32,7 @@ | |||
end | |||
config.include FactoryBot::Syntax::Methods | |||
|
|||
config.before :each do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bcfef68
to
5025149
Compare
@@ -30,7 +32,7 @@ | |||
end | |||
config.include FactoryBot::Syntax::Methods | |||
|
|||
config.before :each do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5025149
to
deb8db3
Compare
before do | ||
create(:setting_version) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
before do | |
create(:setting_version) | |
end | |
before { create(:setting_version) } |
deb8db3
to
84d63ad
Compare
Description:
Based on what we decide in this document. In this PR, we are removing rootstrap-rubocop, adding more rubocop gems and updating the current ones to help us to improve our code style.
Also in this PR we are fixing each linter that appear, after run the new rubocop configuration.
Notes:
Tasks:
Risk:
Preview: