Skip to content

Update RBS for Rack #210

Description

@ParadoxV5

I am currently tinkering with Rack and RBS, using this collection for Rack’s RBS. Unfortunately, it is quite lacklustre. It looks like it was partially prepared by @mame and TypeProf through #36 and never touched since.

  • This RBS document demands a good amount of polishing to be successful.

I’ve inquired about Rack’s opinion on developing RBS themselves through rack/rack#1967. In summary, their consensus is that RBS’s benefits aren’t significant enough to justify the labour of coercing Rack’s duck types to RBS’s static typing. In that discussion, I highlighted: [Update: #232 covers this blockquote]

However, it has possible mistakes and undocumented fields. Examples from Rack::Response alone:

  • The attribute Rack::Response#body should probably follow the SPEC § The Body, but the RBS restricts it to one or an Array of Rack::Lint or nil.
  • I’ve been working around the above with Rack::Response.[], whose args are untyped in the RBS.
  • Rack::Response#each is also missing RBS of &block.
[Significatly modified section starts]
  • Besides filling in the blanks, note that Rack just got a new major version recently (Rack 3). Regarding the leap to Rack 3, a question yet to be answered is if we, as third-party volunteers, should attempt to catch up with Rack’s development (without publishing unusable snapshots) or simply freeze at Rack 2. Keep in Mind that a complete RBS of Rack doesn’t provide a unique convenience (yet) perhaps besides Add rack as a dependency pocke/rbs_rails#174, especially since Rack’s YARDocs and Rack::Lint already detail acceptable types (static or duck) equal to or better than a set of RBS could.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions