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.
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]
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.
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]
[Significatly modified section starts]
Rack::Lintalready detail acceptable types (static or duck) equal to or better than a set of RBS could.