-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update some of Rack’s prevalent classes #232
Conversation
Both this and 0db9d3b are based on the Rack SPEC: https://github.com/rack/rack/blob/v2.2.2/SPEC.rdoc
inferred from source code and Rack SPEC fixes blockquote of ruby#210
I’m not entirely confident with the cookie-related entries. (I don’t work at Rack, duh.)
A note to my Rack RBS updates: I’m assuming `String` means `String` and not `#to_s` nor `#to_str` duck types (unless explicitly documented in Rack’s YARD). [It isn’t unsurprising to see a gap between official intentions and community-volunteered implementations.]
I forgot those convenience aliases I wrote, Lol.
Didn’t forget my convenience aliases this time. 🙃
got to it while doïng `Rack::Response::Helpers`, might as well tap into it
I reviewed that Blocks and Procs’ parameters are not strict, but not for Lambdas. The Lambda can just use the convenience type alias, though.
So… TypeProf’s failed attempt at expanding what might as well be `untyped` – was the cause of our lines being so long?
I’m now satisfied. 🙃 For `Helpers`, however, I need help with the following: ``` #body & #logger (no motivation to write SPEC’s duck types) #session_options (in need of more documentation for Rack) #parse_multipart (my brain raised SystemStackError) ```
This reverts commit 5d2999e.
Not marking the arg optional means the block does not need to concern the number of args (which, yeah, implicitly does not have to match). Partially reverts f68c9eb
Untyped `#body` and `#logger`: they have SPEC-specified duck types that I’m not going to write.
`No type error detected. 🧉`
|
Ah, the test on CI is skipped because |
Thanks for your volunteering 🙌 I think it is not a problem that you do not write RBS for entire of the gem. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change looks good to me, thanks!
I left a comment about testing on CI. Could you confirm the comment?
Insightful suggestion! I compiled a list at #210 (comment). P.S. I also looked at [ |
Yep, I looked into it after my comment and learned that the CI check relies on P.S. Do I list them in |
Great! Thank you 👍 I'll share this list with colleagues who're interested in contributing to RBS.
Ah, good question. Currently, we need to write the dependencies to the three places, which are By the way, only dependencies that are not in the gemspec should be written in the |
Inconvenient indeed, 7262031 fails because the CI tested the Rack RBS using test scripts for Active Record and Action Pack simply because those gems are out of date vs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks!
This PR partially addresses #210 (the updating action, not the Rack 3 concern) by reviewing and updating some of Rack’s commonly-used classes:
Rack::Response
was highlighted in Update RBS for Rack #210’s blockquote.Request::Helpers#body
Request::Helpers#logger
errors
ofMockResponse#initialize
Request::Helpers#session_options
Request::Helpers#parse_multipart
I may have an interest in additionally volunteering for some middleware (but not all of the) classes after this PR. The intention is to ship the above classes first to cover most of Rack’s use cases (hopefully – I don’t wanna do the entire thing on my own 😣).