Skip to content
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 octokit types for better DX #80

Closed
1 task done
cpreston321 opened this issue Feb 7, 2024 · 3 comments
Closed
1 task done

Add octokit types for better DX #80

cpreston321 opened this issue Feb 7, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@cpreston321
Copy link
Member

Describe the feature

Currently the data is any coming back from the fetch endpoint with types you can know what to expect from githubs side.

Additional information

  • Would you be willing to help implement this feature?
@cpreston321 cpreston321 added the enhancement New feature or request label Feb 7, 2024
@cpreston321 cpreston321 self-assigned this Feb 7, 2024
@cpreston321 cpreston321 mentioned this issue Feb 7, 2024
8 tasks
@pi0
Copy link
Member

pi0 commented Feb 7, 2024

Good point. But think github should not break the types and not worth the complexity to add types from another tool that gets propagation time if ever github changes something. (and it is internal)

@cpreston321
Copy link
Member Author

cpreston321 commented Mar 6, 2024

I guess that makes since, I guess it's hard to figure out the data without looking at the response types since the version of the api is defined in the headers for using github REST API itself.

@pi0
Copy link
Member

pi0 commented Mar 6, 2024

Yes. that's why i'm thinking ungh can provide a typed client. (maybe after unjs/ofetch#371)

let's track via #4

@pi0 pi0 closed this as completed Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants