Closed dgmstuart closed 1 month ago
Is it because of this?
SuperDiff is working out whether colours should be used in its own way? But RSpec already has its own ideas about whether colors should be used, and that isn't being taken into account?
Patched in my spec/rails_helper.rb
:
RSpec.configure do |config|
# ...
SuperDiff.configure do |superdiff_config|
superdiff_config.color_enabled = config.color_enabled?
end
end
...but this feels like a bit of a hack?
The SuperDiff
config needs to be inside the RSpec
config block to ensure that RSpec
is fully configured before we try to fetch the color settings from it?
@dgmstuart , thanks for submitting this issue. I agree that since SuperDiff is designed to work seamlessly with RSpec, it should adopt its configuration by default.
Since SuperDiff can be used directly without RSpec, we should make sure to preserve the default behavior when RSpec isn't loaded. But when RSpec is loaded, we should use it if someone hasn't explicitly set SuperDiff.configuration.color_enabled
.
In environments with no colors, it's important to be able to generate test output without color codes, otherwise the output looks like this:
...but it seems like after adding
super_diff
, we always get color in the output, even when explicitly disabled by passing the--no-color
flag to therspec
command.