[BUG]: types for status codes are wrong

[s-h-a-d-o-w]

What happened?

The types for status codes usually only permit one status code, even though the API docs say differently.

Examples: pulls.list(...), repos.listBranches(...)

(Also: #188 - but that issue is more specific. This is obviously a widespread problem and a general fix would be great.)

Versions

Oktokit v19.0.13

Relevant log output

This condition will always return 'false' since the types '200' and '404' have no overlap.ts(2367)

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[wolfy1339]

Can you please tell us what version of typescript you are using, and what your tsconfig looks like?

I can probably have a look at this next week

[s-h-a-d-o-w]

Typescript version: 5.1.6

tsconfig:

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "noEmit": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

[wolfy1339]

Closing as a duplicate of #188

[wolfy1339]

Not exactly the same as #188

[wolfy1339]

I have looked into this a little bit, and currently the types cannot handle an empty response for one status code and a body in another.

As for 404 status codes, they don't seem to be handled in the types at all

[s-h-a-d-o-w]

Glad you decided that it's not a duplicate. 🙂

As for 404 status codes, they don't seem to be handled in the types at all

Yes, after looking into this myself a bit, there's a couple of things:

• I checked your docs for infos on said error behavior - there doesn't seem to be any.
• I think types for errors would still be useful, since those can contain a whole bunch of data. At least by briefly glancing at them (I had to move on to other things), they looked structurally very similar to successful response bodies.

All of that said, in the case of pulls.list(...), it's not 404 but 304/422.
At least 304 admittedly might not be something that one will usually see, since I'm guessing it would require cache handling and presumably, there's no caching in octokit? I.e. when executing that function twice, the second time would not result in a 304?

And overall, it circles back to what I said in my OP - the two function calls I mentioned were just examples of what at least I perceive to be a general problem with non-2xx codes/responses when it comes to types (and possibly docs - which might be subjective).