Convert project to typescript

[wolfy1339]

Had this lying around, and now that @octokit/endpoint was converted, this is the next one down the pipe

Todos

Resolve as part of this PR or make follow up issues

• remove duplication with types from @octokit/endpoint DRY Typescript definitions by using the applicable ones from @octokit/endpoint #54
• add browser tests back. Instead of running all tests, make separate tests which only test the basics, as jest is not compatible with Cypress Add back browser tests #55
• add generated types for request(route, parameters) add generated types for request(route, parameters) #56

[wolfy1339]

@gr2m I've mostly finished this, now would be the time you come by and fix the remainder of the wrnings with your knowledge of the codebase

[gr2m]

see my changes at octokit/endpoint.js#47 introducing pika for building / direct import for modern browsers from https://unpkg.com/

I’ll work on typescript definitions for all endpoints, at least for the endpoint(route, options) interface, I’d like to add the same to @octokit/request, but we can do that in a follow up PR

[wolfy1339]

pika should be in another PR. Since it's not ready yet and depends on upstream to push a patch

[gr2m]

As you prefer 👍

I don’t mind adding the patch as I did in @octokit/endpoint.js until upstream is resolved

[gr2m]

pika should be in another PR. Since it's not ready yet and depends on upstream to push a patch

It’s been fixed upstream, you can copy the setup of endpoint.js.

I also finished the generated types via octokit/endpoint.js#53, I want to add that to @octokit/request as well, but we can do a follow up PR for that. Maybe we can reuse the options types

[wolfy1339]

I'm going to mark this as ready for review, so that CI can run and merge conflicts appear

[wolfy1339]

@gr2m I'm going to need your help with the right types and all. Tests are all broken because of this :/

[gr2m]

I’m looking into it :)

[gr2m]

Some of it got resolved by moving to @pika/pack. Do you mind if I adapt the setup to what we now have with @octokit/endpoint?

[wolfy1339]

No problem, that was something else I was going to do once I had things working properly

[gr2m]

@wolfy1339 I think this is good to go? I’ve added a few TODOs to the pull request description, but we can make follow up issues for these and iterate

[wolfy1339]

Looks fine and dandy

[gr2m]

@octokit/rest is currently using internal APIs
https://github.com/octokit/rest.js/blob/7601bd78c449bf33c2058ce94e2ef3e7d3106c9c/lib/request-with-defaults.js#L3

I can think of two ways to address this

1. Export fetchWrapper, which is what lib/request used to export

2. Move the requestWithHook logic into @octokit/request, maybe as a secondary export?

    import { requestWithHook } from '@octokit/request'

The 1st option is simpler to implement and would be the same as things are today. I would not document it and continue to consider it to be usage of internal APIs which might break at any update.

The 2nd option is more elegant and would have the added benefit that we would no longer need to pin @octokit/request version 🤔

I’ll see how much of an effort the 2nd option will be, if I can’t figure it out tonight I’ll go with the 1st option and make a follow up issue

[gr2m]

Adds a few bytes, but also lots of interesting possibilities

Any thoughts? I’ll sleep over it

[gr2m]

bring it.

[octokitbot]

🎉 This PR is included in version 4.0.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀