Scrape out monkey patching

[pirj]

Sibling PRs:

• Scrape out monkey patching rspec-expectations#1245
• Scrape out monkey patching rspec-mocks#1365
• Fix specs not to use should syntax rspec-support#462

Prerequisite PRs:

• Stop using globally exposed DSL rspec-rails#2420

• Use globally unexposed DSL rspec-support#457

• Add a check to support both RSpec 3 & 4 rspec-rails#2425

• Remove temporary commit. CI is expected to fail on Core/Mocks/Support/Rails steps, as disable_monkey_patching! calls methods that were removed with no replacement. I'll use the maintenance-branch temporary commit hack to fraternize those sibling 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

#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.

Those using the globally-exposed DSL are encouraged to use RSpec.describe/RSpec.shared_examples_for instead.

[JonRowe]

Is there a need for parity? whats the Pr ordering here?

[pirj]

Core first, then Mocks or Expectations no matter the order.

[JonRowe]

Then as this is core, this should be dropped?

[pirj]

Rolled it back.

Code review notes addressed

[pirj]

Build failure is expected. Expectations call the removed config.disable_monkey_patching! method in their specs.

[JonRowe]

Ok, so this is evidently dependant on the others, which of the others can be merged without core? It seems like they should be able to be, but I haven't worked on it. When pinning repositories @pirj can you please explain what will fail without it? If they are all interdependant none of them can be merged until they are all ready for review.

[pirj]

they are all interdependant none of them can be merged until they are all ready for review.

They are interdependent, and they are all ready for review.

[pirj]

@JonRowe

/home/runner/work/rspec-core/rspec-expectations/bin/rspec

An error occurred while loading spec_helper.
Failure/Error: config.disable_monkey_patching!

Do you suggest to send a PR to rspec-expectations's against 4-0-dev to:

- config.disable_monkey_patching!
+ config.disable_monkey_patching! if config.respond_to?(:disable_monkey_patching!)

?

[pirj]

Green 💚