What?
=====
Within FactoryBot::Evaluator, the build strategy was reported either as
a class OR symbol.
A side-effect of this is misreporting within
ActiveSupport::Notifications hooks, since the instrumentation payload
may have strategies listed as e.g. `:create` or
`FactoryBot::Strategy::Create`, even though they semantically represent
the same information.
This introduces a new instance method for all strategies, `to_sym`,
to be called rather than `class`.
This PR adds the Ruby 3.1 and Rails 7 elements to the CI matrix. To support those changes a number of other changes were required:
- Adding a basic Rails 7 Gemfile and updating `Appraisals`
- Quoting 3.0 in the `.github/workflows/build.yml` file so that this entry pulls Ruby 3.0.x and not Ruby 3.1
- Adding the "--disable-error_highlight" value for RUBYOPT in the build environment to disable Ruby 3.1 error highlighting
- Bumping the version of `standard` and configuring it to run against our oldest supported version
closes#1309
It has come up several times over the years that folks want direct
access to the evaluator instance, in most cases to build up more complex
networks of associations. Some folks are already doing this with the
less public `@instance` instance variable.
Given that this is such a minimal change, and it makes the library more
flexible for these more complex use cases, this commit adds an
`attr_reader` for the evaluator instance. Now folks can reference it
without reaching into the private api.
Documentation to follow as part of
https://github.com/thoughtbot/factory_bot/issues/1268
Ruby 2.7 deprecated passing kwargs when the method expects a hash or passing a hash when the method expects kwargs. In factory_bot, this creates the warning:
```
/Users/hparker/code/factory_bot/lib/factory_bot/decorator/new_constructor.rb:9: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
/Users/hparker/code/factory_bot/spec/acceptance/initialize_with_spec.rb:220: warning: The called method `initialize' is defined here
```
We can fix this warning by updating the syntax. We need to include `**kwargs` in the `method_missing` calls when we are on ruby 2.7 or later.
In decorator.rb, adding `**kwargs` alone doesn't work since adding `**kwargs` can change what arguments remain in the `args`.
In this case we have to class eval the method if we are running ruby 2.7. This way the syntax is valid in previous versions and we can use the `...` operator which allows us to avoid changing the arguments passed on in method missing.
Co-authored-by: Lee Quarella <leequarella@gmail.com>
Closes#1336
* removes all the deprecated methods
* removes Ruby 2.3, 2.4 and Rails 4.2 from travis
* bundle updates the test gemfiles
* Removes some pre-5.0 logic from a test helper
* Targets Ruby 2.5 with rubocop and fixes violations
We could also remove support for Rails 5.0 and 5.1, which are now EOL,
but I don't see a strong reason to do that. We don't seem to have to do
anything special to support those versions.
In this PR the cop Style/MethodMissing was split into
Style/MethodMissingSuper and Style/MissingRespondToMissing.
https://github.com/rubocop-hq/rubocop/pull/5811
This commit goes through the disables and updates them to reflect the
appropriate new Cops.
In 241e8e5fb4, this call to `undef_method`
was introduced to suppress the warning printed by Ruby when a method is
redefined.
That warning is only printed when the method is already defined on the
class in question; it isn't printed when the method was inherited from
an ancestor, since overriding methods by shadowing them is a feature.
However, `method_defined?` returns true for inherited methods, which
means we're sometimes undefining methods that wouldn't cause a warning.
If a factory defines an attribute named `object_id` (admittedly not a
great idea), we will undefine the `object_id` method inherited from the
`Object` class, and the following warning will be printed:
factory_bot/evaluator.rb:70: warning: undefining `object_id' may cause serious problems
By only undefining the method if it's defined on the current class, we
can avoid undefining inherited methods and triggering this warning.
To make it obvious that these are non-standard cases.
Also add respond_to_missing? to the decorator.
We are using Style/MethodMissing rather than
Style/MethodMissingSuper and Style/MissingRespondToMissing because we
are still on RuboCop 0.54.
