Support custom validators autoloading in Rails >= 6

[dm1try]

The problem: When some Grape application is mounted to Rails the default Rails autoloading rules cannot be applied to the custom validators because the validator class name is not involved when we use the params DSL, ex. requires :id, custom: true but the autoloader relies on a class name to a file path mapping(Custom => some/path/custom.rb).

This PR solves the mentioned problem for Rails >= 6.0 where the default autoloader is zeitwerk.
It solves the problem in two steps:

1. we allow to define the callback for loading a validator class when the validator is not "registered", so users can create own autoloading mechanism instead of using an explicit require each time.

Grape.config.on_uknown_validator << ->(validator_name) {
   require "validators/#{validator_name}"
   ::Validators.const_get(validator_name.camelcase)
 }

# validators/custom.rb
module Validators
      class Custom < Grape::Validations::Validators::Base
      ...

# app/api.rb
  ...
  requires :id, custom: true

2. we add the Railtie to be able to hook into a default Rails autoloader(zeitwerk), we check if it's enabled first, then add a specific code for lookup a validator class name based on its DSL name(ex. custom => Grape::Validations::Validators::Custom) and add a hook for de-registering validators on reloading(mostly related to a development environment, where the files are lazy loaded/unloaded). The implementation can be certainly extended for different loaders/Rails versions.

the example, to use custom: true in params DSL
you should put the implementation in app/lib/grape/validations/validator/custom.rb of your Rails app(it looks like a legit way)

# app/lib/grape/validations/validator/custom.rb
module Grape
  module Validations
    module Validators
      class Custom < Base
        def validate_param!(attr_name, params)
          params[attr_name] = 'my_validator_did_this'
        end
      end
    end
  end
end

ref #1178
supersedes #1186

• acceptance test (maybe some bash script :) not sure)
• changelog
• make rubocop happy

[dblock]

I haven't worked with Rails for a long time, so I think I'm missing a lot of context.

I see we're injecting Rails::Railtie early. That alone deserves its own PR as it clearly will have some impact on Grape loaded with Rails. I would like to understand the implications, see updated documentation, possibly integration tests and understand why it's awesome.

Next, what's wrong with Grape current custom validators? Why would I want Rails in the way?
Sounds like we just want to auto-load validators from Rails validators?

Finally, why and what is Zeitwerk and why should Grape care?

[dm1try]

@dblock good points, I updated the description.

I see we're injecting Rails::Railtie early. That alone deserves its own PR as it clearly will have some impact on Grape loaded with Rails. I would like to understand the implications, see updated documentation, possibly integration tests and understand why it's awesome.

I could split the PR, but the parts do not worth much separately.

Next, what's wrong with Grape current custom validators? Why would I want Rails in the way? Sounds like we just want to auto-load validators from Rails validators?

I think, it's about the consistency. When you are working with Grape on Rails and all your code is loaded implicitly but not custom validators code it feels inconsistent and raises the issues like #1178.

Finally, why and what is Zeitwerk and why should Grape care?

yeah) the code could be separated to own gem for sure.

actually, I do not care much about this PR. I recently found some incomplete PRs in my Github profile and it was the try to complete some of them) not a big deal at all. just some Ruby practice.

[dblock]

Thanks @dm1try, let's get this over the line?

• Add an integration with Rails 6 into https://github.com/ruby-grape/grape/tree/master/spec/integration that has a custom validator.
• I'd like the naming to be validator, but let me know if you have strong opinions why it shouldn't be that short. It's easy to name something and it's really hard to change it, so worth another conversation.

[dblock]

If the config option is validator, this also can just be validator since it exists in the Grape::Railtie namespace.

[dblock]

def validator(name)

[dm1try]

I'd like the naming to be validator, but let me know if you have strong opinions why it shouldn't be that short. It's easy to name something and it's really hard to change it, so worth another conversation.

in my opinion, the name should point that this is some callback/-s but not just some property.
so either on_something(when something have happened) or something_missing(when something have missed, like Ruby's const_missing) are more preferable options.

[dblock]

I'd like the naming to be validator, but let me know if you have strong opinions why it shouldn't be that short. It's easy to name something and it's really hard to change it, so worth another conversation.

in my opinion, the name should point that this is some callback/-s but not just some property. so either on_something(when something have happened) or something_missing(when something have missed, like Ruby's const_missing) are more preferable options.

Ok, I'm cool with it. LMK when this is rebased and ready to merge.

[dblock]

Interested in finishing this @dm1try ?

[dm1try]

@dblock nope, let's close it for now.
anyway this issue should be resolved in conjunction with other issues related to the new Rails autoloader(ex. #2238) and maybe separated as a gem.