Remove RSpec/Capybara/FeatureMethods

rubocop / rubocop-rspec

Code style checking for RSpec files.

https://docs.rubocop.org/rubocop-rspec

MIT License

794 stars 272 forks source link

Remove RSpec/Capybara/FeatureMethods #1876

Closed ydah closed 1 month ago

ydah commented 2 months ago

Fix: https://github.com/rubocop/rubocop-rspec/issues/1852

Before submitting the PR make sure the following are checked:

[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Updated documentation.
[x] Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
[x] The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

If you have modified an existing cop's configuration options:

[x] Set VersionChanged: "<<next>>" in config/default.yml.

pirj commented 2 months ago

Nice! A small note on config, otherwise looks good. Thank you!

I’m sorry if I’ve missed that in some other ticket/pr/discussion, is there anything that’s stopping us from releasing 3.0 with those breaking changes as our next release? I’ve seen that we have two branches now.

bquorning commented 1 month ago

I’m sorry if I’ve missed that in some other ticket/pr/discussion, is there anything that’s stopping us from releasing 3.0 with those breaking changes as our next release? I’ve seen that we have two branches now.

No, I don’t think there’s a whole lot more to be done before releasing a v3.0 ✨ I started a discussion at #1880.

bquorning commented 1 month ago

@ydah Could you please rebase once again?

Related: Should I enable the “Always suggest updating pull request branches” feature for the repo?

Whenever there are new changes available in the base branch, present an “update branch” option in the pull request.

That would mean other maintainers could easily rebase a PR (or merge origin/master in), but perhaps at the cost of (many) more commits, and a more confusing workflow for the contributor whose local branch no longer matches the remote.

ydah commented 1 month ago

@bquorning I did it!

That would mean other maintainers could easily rebase a PR (or merge origin/master in), but perhaps at the cost of (many) more commits, and a more confusing workflow for the contributor whose local branch no longer matches the remote.

I think it's a very good point of view. IMO, but we don't want to rush the merge. And confuse PR authors. So I think it's fine the way it is.

bquorning commented 1 month ago

does rubocop-capybara’s spec suite still pass with this?

I tried it locally, and the specs and most of the rubocop check pass.

bquorning commented 1 month ago

I ran rubocop with this branch of rubocop-rspec on a rather large project at work, and the only unexpected issue I encountered was the problem with rubocop-rspec_rails described in #1884 (which is easily fixed after our next release). This PR is ready to merge!