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

Scrape out monkey patching #1365

Merged
merged 1 commit into from
Dec 26, 2020
Merged

Scrape out monkey patching #1365

merged 1 commit into from
Dec 26, 2020

Conversation

pirj
Copy link
Member

@pirj pirj commented Dec 18, 2020

Sibling PRs:

Prerequisite PRs:

http://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero_monkey_patching_mode

we do want to encourage people to switch to the new syntax, so we plan to make RSpec 3 print a warning on first usage of any the old syntax methods (should, should_not, should_receive, etc) unless the should syntax has been explicitly enabled. This should nudge folks towards the new syntax while keeping RSpec friendly to new users and will pave the way for the old syntax to be disabled by default in RSpec 4.

zero-monkey-patching mode for RSpec... We plan for these config options to become the defaults in RSpec 4.0, so that RSpec 4.0 will have zero monkey patching out of the box.

As for "disabled by default" vs "completely removed" and "default, out of the box" vs "impossible" I can only say that RSpec 4 was probably planned to be released earlier, as:

we'll probably be dropping support for 1.8.7 in RSpec 4

but we've also dropped 1.9, 2.0, 2.1 and 2.2

rspec/rspec-core#2301 (comment)

In RSpec 4, we plan to extract all monkey patching from RSpec and move it into a separate gem, so that monkey patching is opt-in instead of opt-out and users have to explicitly install and load a gem to get it.

rspec-should (or rspec-monkey as it's also about exposing example group DSL in the top-level/Module?) will be released later.

Those using the monkey-patched should syntax are not encouraged to update to RSpec 4 until this gem is extracted.

@pirj pirj self-assigned this Dec 18, 2020
@pirj pirj force-pushed the remove-monkey-patching branch 3 times, most recently from 0ce50c9 to 2b5a8e9 Compare December 19, 2020 00:35
@pirj pirj marked this pull request as ready for review December 19, 2020 00:52
http://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero_monkey_patching_mode

> we do want to encourage people to switch to the new syntax, so we plan to make RSpec 3 print a warning on first usage of any the old syntax methods (should, should_not, should_receive, etc) unless the should syntax has been explicitly enabled. This should nudge folks towards the new syntax while keeping RSpec friendly to new users and will pave the way for the old syntax to be disabled by default in RSpec 4.

> zero-monkey-patching mode for RSpec...  We plan for these config options to become the defaults in RSpec 4.0, so that RSpec 4.0 will have zero monkey patching out of the box.

As for "disabled by default" vs "completely removed" and "default, out
of the box" vs "impossible" I can only say that RSpec 4 was probably planned to
be released earlier, as:

> we'll probably be dropping support for 1.8.7 in RSpec 4

but we've also dropped 1.9, 2.0, 2.1 and 2.2

rspec/rspec-core#2301 (comment)

> In RSpec 4, we plan to extract all monkey patching from RSpec and move it into a separate gem, so that monkey patching is opt-in instead of opt-out and users have to explicitly install and load a gem to get it.

`rspec-should` (or `rspec-monkey` as it's also about exposing example
group DSL in the top-level/Module?) will be released later.

Those using the monkey-patched `should` syntax are not encouraged to
update to RSpec 4 until this gem is extracted.
remove-monkey-patching
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats this dependant on?

Copy link
Member Author

@pirj pirj Dec 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Core should be merged first.
Core's 4-0-dev has this:

        RSpec::Mocks.configuration.tap do |config|
          config.syntax = :expect

and would fail if this was merged first.
Core's remove-monkey-patching's specs pass when run against 4-0-dev of Mock and Expectations.

Mocks and Expectations' PRs can be merged in any order.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok, this explanation resolves a point I had on core, in future it'd be useful if this sort of explicit information is in the PR description, or commented on the branch like this so people know why, I have an alternate solution.

@JonRowe
Copy link
Member

JonRowe commented Dec 26, 2020

Merging as build failure is rspec-rails on Ruby 3.1 (head) due to no available minitest version.

@JonRowe JonRowe merged commit ef886d3 into 4-0-dev Dec 26, 2020
@JonRowe JonRowe deleted the remove-monkey-patching branch December 26, 2020 10:12
yujinakayama pushed a commit to yujinakayama/rspec-monorepo that referenced this pull request Oct 19, 2021
…onkey-patching

Scrape out monkey patching

---
This commit was imported from rspec/rspec-mocks@ef886d3.
@pirj pirj added this to the 4.0 milestone Jan 25, 2024
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

Successfully merging this pull request may close these issues.

2 participants