Open alyssais opened 6 years ago
This generally shouldn't be an issue, after all the first thing require 'rspec/rails
does is to load rspec/core
, theres not really a nice way to delay this check other than to say that its a requirement to include rspec-core first. Although maybe we could perform the check in rspec core too and load it that way, WDYT @myronmarston
WFYT @myronmarston
I have no idea what WFYT stands for...
Anyhow, IMO it's an anti pattern that rspec-expectations
has knowledge of how to hook itself into rspec-core
. Instead, we should change rspec-core to do that. Want to work up a PR to fix it, @alyssais ?
WFYT was WDYT typo'd :)
Anyhow, IMO it's an anti pattern that rspec-expectations has knowledge of how to hook itself into rspec-core. Instead, we should change rspec-core to do that.
Yep I agree
Want to work up a PR to fix it, @alyssais ?
Will see if I have time at the weekend :)
Not sure if this is the right place to report this, but it seemed the most sensible.
The rspec-expectations matcher DSL checks at load time whether
RSpec.configuration
is defined, and only includes itself if it is:https://github.com/rspec/rspec-expectations/blob/a81b0678bd504c10da5475d73a676f6f60c1e9d7/lib/rspec/matchers/dsl.rb#L97
This causes problems if, e.g., you have a Gemfile like this:
When rspec-collection_matchers is loaded, it loads rspec-expectations, but rspec-core has not yet been loaded. This means that the matcher DSL will not be available in example groups, and so scoped aliased and negated matchers cannot be used without manually extending
RSpec::Matchers::DSL
.