Deprecate GitHub-API

[j-rewerts]

I'd like to open up the discussion around deprecating this package. GitHub itself maintains a great JavaScript client library in Octokit. I think due to the popularity of our library, it almost hurts the community since we're splitting efforts across multiple projects.

I propose we come up with a rough timeline to deprecating this package and formally recommending people move to Octokit. We could still take security fixes or certain bug fixes for a period of time.

[j-rewerts]

@clayreimann @CodyGramlich @WJXHenry @kylejeske Lets get a little discussion on this.

[j-rewerts]

In terms of timelines, what if we did something like:

June-July

• review all open pull requests, either closing them or merging them.
• look through the ~100 open issues and determine if they're features, bugs, questions and so on.

July-August

• submit new PRs to resolve the reported bugs and features

September-December

• put a deprecation notice on the site and the readme
• refuse all new feature issues
• resolve security vulnerabilities
• if questions come in, recommend they use OctoKit, then close the issue (this may be a bit harsh)

By the end of the year, this library would become a lot more quiet.

[kylejeske]

@j-rewerts While I'm typically a proponent of multiple efforts, as I believe they can advance the general common good. However, in this particular case, I'm in agreement.

As for your timeline and suggested migration path. My only suggestion would be to list a notice much sooner, perhaps even a notice of "intent to deprecate"?

[alundiak]

I have my small project for experiments with GitHub API v4 using GraphQL, and the reason I used github-tools aka github-api because I also have code using GitHub API v3 (REST). So, if github-tools will never support GraphQL v4 API, then sure thing => DEPRECATE.

Anyhow, github-tools good, stable tool. For example, I don't know if @octokit provide code/API to work with Gists. UPD Found - https://octokit.github.io/rest.js/#octokit-routes-gists

[j-rewerts]

@kylejeske I'll add a notice of deprecation soon. Thanks for the suggestion.

@alundiak My hope is that by joining the github-api community with the OctoKit community, we'll have a better overall JavaScript client, though that remains to be seen. Currently, no one on the github-api project actually gets paid to work on it, which makes it a bit tricky to get active contributions.

Also, there are no plans for github-api to support the GraphQL API as far as I'm aware.

[gr2m]

👋 hey friends, I'm the maintainer of the Octokit libraries for Node and browsers. I've only found out about this issue now. I wonder if there is anything I can help with? Maybe there are features that people very much appreciate in github-api that are lacking in Octokit? Please let me know if there is anything I can help with

[j-rewerts]

Thanks for reaching out @gr2m! I think this is a great direction to go down. Having you onboard to help merge our communities would be super helpful!

I'm guessing that as we get more serious about deprecation, more users will start posting there opinions. Maybe I could ask these users to create an issue in the Octokit repo?

[gr2m]

Yes, of course. Maybe we could collaborate on a migration guide that you could add to this repository as part of the deprecation?

[AntonOfTheWoods]

Absolutely wonderful. The problem is that octokit was never a browser-friendly project (lots of node-specific stuff that needs polyfilling, which projects like vitejs have deep philosophical problems with) and @gr2m was told he was no longer needed by Github.

So now this project is abandoned and Octokit might find developers one day. In the meantime we are reduced to nasty hacks for things like typescript support.