OpenAPI 3.1 support

[jcoyne]

Until 3.1 is supported, it would be nice to indicate that this supports the OpenAPI 3.0 spec.

[jamietanna]

It also appears that if a v3.1 spec is used, no validation is performed? Changing the spec's version from v3.0.2 to v3.1.0 on a failing schema results in no errors 🤔

[mc-chinju]

I checked that it works, and it seems that if you are using OpenAPI 3.1, the error is caused by the link.
I changed 3.0. to 3. and it worked.
https://github.com/interagent/committee/blob/master/lib/committee/drivers.rb#L53

[chrishough]

❓ Great point @jcoyne, and I am noticing failures with all things working by just bumping the OpenAPI specification version to just 3.1.0 i.e "openapi": "3.1.0", is there a roadmap to upgrade to 3.1.0?

  1) /users GET /index complies to the API schema
     Failure/Error: assert_request_schema_confirm

     Committee::InvalidRequest:
       `GET /users` undefined in schema (prefix: nil).
     # ./spec/requests/users_spec.rb:40:in `block (3 levels) in <main>'

Finished in 0.08728 seconds (files took 1.06 seconds to load)
18 examples, 1 failure, 4 pending

[modosc]

quick workaround:

module CommitteeOpenApi31Support
  extend ActiveSupport::Concern

  class_methods do
    def load_from_data(hash, schema_path = nil, parser_options: {})
      # pretend to be v3.0.0, see https://github.com/interagent/committee/issues/352
      hash["openapi"] = "3.0.0"
      super
    end
  end
end

Committee::Drivers.prepend CommitteeOpenApi31Support

[chrishough]

That is a great idea @modosc I will have to try that

[quaelin]

I've got a bunch of Ruby apps using OpenAPI 3.1 and I'm also very curious about the state of this effort. Is there a plan to add support for 3.1?

[brandur]

@quaelin I'm afraid to say that as far as I'm aware, there aren't any active plans for any major improvements to Committee (although if anyone else is working on one, let me know). The gem's come in and out of phases of active maintainership, but as more recently hit a lull once again. As the original author I've stepped back in to provide maintenance-level stewardship and releases, but I haven't used the gem in any projects in about ten years, and am not actively developing it.

[jcoyne]

@brandur Thank you for stating your intentions. That is helpful for planning. Thanks also for your work on this project in the past.

[chrishough]

@quaelin or others, has anyone expressed interest to take this project over to actively maintain it?

[geemus]

@chrishough Good question. @ydah has been helping with maintenance and I've also been trying to step up more to help out. So I think there is a bit more support/work than before. That said, both of us have somewhat limited capacity and would always welcome more help. In particular, we have some catching up to do on issues and things. If there are particularly high priorities and/or low hanging fruit, please do feel free to direct my attention toward them and I'll try to get on them ASAP. From what I've seen, full support of 3.1 will probably be a little more involved. But on the plus side, I think we can start adding support for parts of it without waiting to support it all (that's what I'm seeing in documentation relating to the migration and updating related dev tools anyway). So if there are some portions that are higher priority that would be great to know. Also I'd certainly welcome discussion and/or PRs to help move things forward. If you are interested in helping maintain above and beyond that we're also happy to discuss that.