-
Notifications
You must be signed in to change notification settings - Fork 572
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
Add Types #375
Add Types #375
Conversation
Working on Errors now. I think I found a good pattern that will also support proper type guarding 😄 ~ edit ~ 😉 import { Errors } from 'undici'
{
function f (): Errors.HeadersTimeoutError | Errors.SocketTimeoutError { return }
const e = f()
if (e.code === 'UND_ERR_HEADERS_TIMEOUT') {
expectAssignable<Errors.HeadersTimeoutError>(e)
} else if (e.code === 'UND_ERR_SOCKET_TIMEOUT') {
expectAssignable<Errors.SocketTimeoutError>(e)
}
} |
@Ethan-Arrowood do you intend to continue on this? |
I've been focusing on trying to finish the iterable body feature, but since I'm not making much progress there I can shift my focus to finishing these up. Do you think we should publish these types here or in definitely typed? |
And like that, this is ready for review! I mainly relied on the README file for details. Some questions:
|
I'll let @ronag respond about
Yes, but there are a lot of those (
It allows the developer to not create a closure. It's passed through to the function. It's a C/C++ technique used in libuv and a lot of other places.
I'm lost. Headers are just strings and there are known headers. I don't know about Node.js types for those. |
Okay will do.
I was also thinking about using a generic. I'll try and do a bit more research on what it is and see if I can come up with. a better type
Yeah in other parts of the types where headers is an array rather than a key/value object, I used |
Nope. |
Answer: no. Technically a method can be any string. If someone really wanted to they could create custom methods
Answer: no. Will remove the typing now and fix the readme too
For simplicity, I'm keeping this as unknown. Using a generic to pass through a type is no safer than type casting an unknown value.
@ronag ^
Its defined inside node http types as IncomingRequestHeaders. I've switched over to using that now. I'm still tempted to replace it with |
I don't know if it matters too much but two of my previous commits weren't GPG signed. I've amended the latest one. |
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.
lgtm, I think we can land this now.
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.
LGTM.
* init type work * add error types * fix up error tests and add client.request * complete client types * complete pool and fix up some existing tests * touch up types and add tests * add type tests to action workflow * fix dispatch return type * export errors and fix tests
Ready for review!
🌟 This should get us started on types. Keeping as draft until branch is at v1 parity. Other's are welcome to contribute types as well (@delvedor). Please pr to my fork'stypes
branch with whatever additions/modifications you make.I'm pretty confident with the
index.d.ts
file exports. I spent a good deal of time researching and this seems the most correct. Other TS folk please feel free to review and provide suggestions if improvements can be made ❤️Closes #289