Read route metadata via readers instead of route.options[] - #983
Conversation
Danger ReportWarnings
MarkdownsHere's an example of a CHANGELOG.md entry: * [#983](https://github.com/ruby-grape/grape-swagger/pull/983): Read route metadata via readers instead of route.options[] - [@ericproulx](https://github.com/ericproulx). |
There was a problem hiding this comment.
Pull request overview
This PR refactors grape-swagger’s route metadata access to use Grape’s public route reader methods (e.g., route.success, route.tags, route.body_name) instead of reaching into route.options[...], aiming to stay compatible as Grape restructures its internal options storage.
Changes:
- Updated endpoint/document generation to consume route metadata via reader methods (including dynamic producer reads via
public_send). - Updated OperationId generation to use
route.nicknameinstead ofroute.options[:nickname]. - Changed
build_body_parameterto accept a resolvedbody_namevalue and updated specs accordingly.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| spec/lib/move_params_spec.rb | Updates specs for the new build_body_parameter(name, body_name) signature. |
| lib/grape-swagger/endpoint.rb | Switches route metadata reads (tags, deprecated, security, summary/detail, produces, hidden, etc.) to reader methods. |
| lib/grape-swagger/doc_methods/operation_id.rb | Uses route.nickname for operationId generation. |
| lib/grape-swagger/doc_methods/move_params.rb | Passes route.body_name into build_body_parameter and updates its signature. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ca2353d to
8b9ddff
Compare
grape-swagger reached into the route's options Hash for metadata. Replace every route.options[...] read with the equivalent reader method — including the success/failure aliases of entity/http_codes and the dynamic producer lookup (via public_send) — so grape-swagger consumes routes through their public method interface rather than the internal options Hash. This lets Grape restructure route.options (reserving it for user custom keys) without breaking grape-swagger. build_body_parameter now takes a resolved body_name value rather than the options Hash. The readers resolve on supported Grape (verified on 2.4.0). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
8b9ddff to
b4a72a1
Compare
|
@ericproulx great job as usual! 👍 |
on it, investigating the grape HEAD issue. Merged few things today |
|
I will update and merge this PR |
Consume route metadata through the route's public reader methods instead of reaching into
route.options[...].What changed
Every
route.options[...]read inlib/is replaced with the equivalent reader:deprecated,security,summary,detail,produces,is_array,hidden,nickname,tags→ their readerssuccess/failure(keyword aliases ofentity/http_codes) →route.success/route.failurebody_name→ resolved by the caller asroute.body_name;build_body_parameternow takes the resolved value:formats/:content_types/:produces) →route.public_send(producer):desc/:default_response→route.desc/route.default_responseThere is one remaining route.options[...] read: route.options.key?(:tags) in method_object (see "Behavior note" below) — no reader distinguishes "tags absent" from "tags explicitly nil", so presence has to be checked on the raw options hash
Why
Grape is moving desc metadata toward first-class readers (as it already did for
params/anchor/requirements) and wants to reserveroute.optionsfor user custom keys. Consuming routes through their method interface means grape-swagger keeps working when Grape restructures the options bag. The readers resolve on the currently-supported Grape (verified on 2.4.0).Behavior note (
detail: nil)summary_object/description_objectpreviously gated onroute.options.key?(:detail); they now readroute.detail. The only observable difference is whendetail:is set explicitly tonil— it is now treated the same as an absentdetail(the description holds the text and there is no separate summary), which is the more sensible reading of "no detail". Covered by a new example inapi_swagger_v2_detail_spec.rb.Behavior note (tags: nil)
Unlike detail, an explicit tags: nil is not treated as absent — it suppresses the default tag fallback (tag_object) entirely, matching the pre-migration
route.options.fetch(:tags, tag_object(route, path))behavior. This is intentionally asymmetric with detail:detail: nilreads as "no separate detail text," whiletags: nilreads as "the user explicitly opted out of default tagging." Covered by the new example inendpoint_versioned_path_spec.rb.Tests
Full suite: 515 examples, 2 failures (both pre-existing on
master, unrelated to this change), 2 pending — no new failures.build_body_parameter's unit specs are updated for the value-based signature.🤖 Generated with Claude Code