Rails/HasManyOrHasOneDependent Cop & ActiveResource relations

[OtherCroissant]

Rails/HasManyOrHasOneDependent Cop wants me to define a :dependent option for a has_many relation for a class that extends from a ActiveResource model. Though, for a ActiveResource relation :dependent is not a valid option.

---

Expected behavior

The Rails/HasManyOrHasOneDependent error should not be triggered for ActiveResource models.

Actual behavior

Rails/HasManyOrHasOneDependent is detected

Steps to reproduce the problem

Include ActiveResource in your project:

gem 'activeresource', require: 'active_resource'

Create a ActiveResource class for talking to a REST API:

module API
  class User < ActiveResource::Base
    has_many :projects, class_name: 'API::Project'
  end
end

Running Rubocop gives the following:

app/models/api/user.rb:4:5: C: Rails/HasManyOrHasOneDependent: Specify a :dependent option.
    has_many :projects, class_name: 'API::Project'
    ^^^^^^^^

but If you add the :dependent option, ActiveResource will throw an exception on runtime:

Failure/Error: has_many :projects, class_name: 'API::Project', dependent: :destroy

ArgumentError:
  Unknown key: :dependent. Valid keys are: :class_name

RuboCop version

0.59.0 (using Parser 2.5.1.2, running on ruby 2.5.1 x86_64-darwin17)

[yskkin]

Does this mean that a module for ActiveRecord is no longer linted?

module Foo
  extend ActiveSupport::Concern

  included do
    has_many :bazs # 0.59.1 emits warning for this line
  end
end

class Bar < ApplicationRecord
  include Foo
end

[koic]

@yskkin Thanks for the feedback. I think that it is better to check also when using mix-in.
I commented an idea on #6298 (comment).

The following is a quotation.

This is one idea. It seems better to check whether it is ActiveResource::Base instead of ActiveRecord::Base or ApplicationRecord. It does not check if the superclass is ActiveResource::Base.

What do you think about it?

Cc @tejasbubane @bbatsov

[koic]

I opened a PR #6318 that implements the above idea.