Open
Description
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 theSPEC
§ The Body, but the RBS restricts it to one or an Array ofRack::Lint
ornil
.- 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
Labels
No labels