Skip to content

Update RBS for Rack #210

Open
Open
@ParadoxV5

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

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions