-
Notifications
You must be signed in to change notification settings - Fork 761
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
Deprecate GitHub-API #564
Comments
@clayreimann @CodyGramlich @WJXHenry @kylejeske Lets get a little discussion on this. |
In terms of timelines, what if we did something like: June-July
July-August
September-December
By the end of the year, this library would become a lot more quiet. |
@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"? |
I have my small project for experiments with GitHub API v4 using GraphQL, and the reason I used github-tools aka 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 |
@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. |
👋 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 |
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? |
Yes, of course. Maybe we could collaborate on a migration guide that you could add to this repository as part of the deprecation? |
Instead of the third party github-api we were using. We noticed that the author of the library we were using has suggested it should be deprecated[1], and we've also run into a few problems using it. In switching we've also (we hope) solved the 422 errors we were seeing when saving to GitHub. Co-authored-by: Chris Lowis <[email protected]> [1]: github-tools/github#564
Absolutely wonderful. The problem is that octokit was never a browser-friendly project (lots of node-specific stuff that needs polyfilling, which projects like 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. |
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.
The text was updated successfully, but these errors were encountered: