octokit.js
v4.0.2
Le SDK GitHub a inclus pour les navigateurs, Node.js et Deno.
Le package octokit intègre les trois principales bibliothèques octokit
Octokitoctokit.rest Méthodes de point de terminaisonoctokit.request()| Navigateurs | Chargez octokit directement à partir d'ESM.Sh < script type =" module " >
import { Octokit , App } from "https://esm.sh/octokit" ;
</ script > |
|---|---|
| Nez | Chargez octokit directement à partir d'ESM.Sh import { Octokit , App } from "https://esm.sh/octokit?dts" ; |
| Nœud | Installez avec import { Octokit , App } from "octokit" ; |
Important
Au fur et à mesure que nous utilisons des exportations conditionnelles, vous devrez adapter votre tsconfig.json en définissant "moduleResolution": "node16", "module": "node16" .
Voir les documents TypeScript sur package.json "Exports".
Voir ce guide utile sur la transition vers l'ESM de @sinSorhus
Octokit Octokit minimal autonome : @octokit/core .
Le client Octokit peut être utilisé pour envoyer des demandes à l'API REST de GitHub et aux requêtes à l'API GraphQL de GitHub.
Exemple : Obtenez le nom d'utilisateur de l'utilisateur authentifié.
// Create a personal access token at https://github.com/settings/tokens/new?scopes=repo
const octokit = new Octokit ( { auth : `personal-access-token123` } ) ;
// Compare: https://docs.github.com/en/rest/reference/users#get-the-authenticated-user
const {
data : { login } ,
} = await octokit . rest . users . getAuthenticated ( ) ;
console . log ( "Hello, %s" , login ) ;Les options les plus couramment utilisées sont
| nom | taper | description |
|---|---|---|
userAgent | String | La définition d'un agent utilisateur est requise pour toutes les demandes envoyées aux API de plate-forme de GitHub. L'agent utilisateur est par défaut quelque chose comme ceci: const octokit = new Octokit ( {
userAgent : "my-app/v1.2.3" ,
} ) ; |
authStrategy | Function | Par défaut à Voir l'authentification ci-dessous. |
auth | String ou Object | Définissez sur un jeton d'accès personnel, sauf si vous avez modifié l'option Voir l'authentification ci-dessous. |
baseUrl | String | Lorsque vous utilisez avec GitHub Enterprise Server, définissez const octokit = new Octokit ( {
baseUrl : "https://github.acme-inc.com/api/v3" ,
} ) ; |
Options avancées
| nom | taper | description |
|---|---|---|
request | Object |
Node uniquement
L'option |
timeZone | String | Définit l'en-tête de const octokit = new Octokit ( {
timeZone : "America/Los_Angeles" ,
} ) ;L'en-tête du fuseau horaire déterminera le fuseau horaire utilisé pour générer l'horodatage lors de la création de commits. Voir la documentation des fuseaux horaires de GitHub. |
throttle | Object | Par défaut, les demandes sont réactivées une fois et les avertissements sont enregistrés en cas de atteinte à un taux ou à la limite de taux secondaire. {
onRateLimit : ( retryAfter , options , octokit ) => {
octokit . log . warn (
`Request quota exhausted for request ${ options . method } ${ options . url } `
) ;
if ( options . request . retryCount === 0 ) {
// only retries once
octokit . log . info ( `Retrying after ${ retryAfter } seconds!` ) ;
return true ;
}
} ,
onSecondaryRateLimit : ( retryAfter , options , octokit ) => {
octokit . log . warn (
`SecondaryRateLimit detected for request ${ options . method } ${ options . url } `
) ;
if ( options . request . retryCount === 0 ) {
// only retries once
octokit . log . info ( `Retrying after ${ retryAfter } seconds!` ) ;
return true ;
}
} ,
} ;Pour se retirer de cette fonctionnalité: new Octokit ( { throttle : { enabled : false } } ) ; L'étranglement dans un cluster est pris en charge à l'aide d'un backend Redis. Voir |
retry | Object | Pour se retirer de cette fonctionnalité: new Octokit ( { retry : { enabled : false } } ) ; |
Par défaut, le client API Octokit prend en charge l'authentification à l'aide d'un jeton statique.
Il existe différents moyens d'authentification qui sont pris en charge par GitHub, qui sont décrits en détail sur Octokit / Authentication-STRAtéggies.js. Vous pouvez définir chacun d'eux comme l'option authStrategy Constructor et transmettre les options de stratégie comme option auth Constructor.
Par exemple, afin de s'authentifier en tant qu'installation de l'application GitHub:
import { createAppAuth } from "@octokit/auth-app" ;
const octokit = new Octokit ( {
authStrategy : createAppAuth ,
auth : {
appId : 1 ,
privateKey : "-----BEGIN PRIVATE KEY-----n..." ,
installationId : 123 ,
} ,
} ) ;
// authenticates as app based on request URLs
const {
data : { slug } ,
} = await octokit . rest . apps . getAuthenticated ( ) ;
// creates an installation access token as needed
// assumes that installationId 123 belongs to @octocat, otherwise the request will fail
await octokit . rest . issues . create ( {
owner : "octocat" ,
repo : "hello-world" ,
title : "Hello world from " + slug ,
} ) ; Vous pouvez utiliser l' App ou les SDK OAuthApp qui fournissent des API et un câblage interne pour couvrir la plupart des cas d'utilisation.
Par exemple, pour implémenter ce qui précède à l'aide App
const app = new App ( { appId , privateKey } ) ;
const { data : slug } = await app . octokit . rest . apps . getAuthenticated ( ) ;
const octokit = await app . getInstallationOctokit ( 123 ) ;
await octokit . rest . issues . create ( {
owner : "octocat" ,
repo : "hello-world" ,
title : "Hello world from " + slug ,
} ) ;En savoir plus sur le fonctionnement des stratégies d'authentification ou de la façon de créer le vôtre.
Par défaut, le client API Octokit n'utilise pas les variables d'environnement du serveur proxy standard. Pour ajouter la prise en charge des serveurs proxy, vous devrez fournir un client HTTPS qui les prend en charge comme undici.ProxyAgent() .
Par exemple, cela utiliserait un ProxyAgent pour faire des demandes via un serveur proxy:
import { fetch as undiciFetch , ProxyAgent } from 'undici' ;
const myFetch = ( url , options ) => {
return undiciFetch ( url , {
... options ,
dispatcher : new ProxyAgent ( < your_proxy_url > )
} )
}
const octokit = new Octokit ( {
request : {
fetch : myFetch
} ,
} ) ; Si vous écrivez un module qui utilise Octokit et est conçu pour être utilisé par d'autres personnes, vous devez vous assurer que les consommateurs peuvent fournir un autre agent pour votre Octokit ou comme paramètre à des appels spécifiques tels que:
import { fetch as undiciFetch , ProxyAgent } from 'undici' ;
const myFetch = ( url , options ) => {
return undiciFetch ( url , {
... options ,
dispatcher : new ProxyAgent ( < your_proxy_url > )
} )
}
octokit . rest . repos . get ( {
owner ,
repo ,
request : {
fetch : myFetch
} ,
} ) ; Si vous obtenez l'erreur suivante:
Fetch n'est pas défini. Veuillez passer une implémentation Fetch en tant que nouveau octokit ({request: {fetch}}).
Cela signifie probablement que vous essayez d'exécuter Octokit avec une version non soutenue de NodeJS. Octokit nécessite le nœud 18 ou supérieur, qui comprend une API de récupération native.
Pour contourner ce problème, vous pouvez fournir votre propre implémentation fetch (ou une version intégrée comme node-fetch ) comme ceci:
import fetch from "node-fetch" ;
const octokit = new Octokit ( {
request : {
fetch : fetch ,
} ,
} ) ; Il existe deux façons d'utiliser l'API GitHub REST, le octokit.rest.* Méthodes de point de terminaison et octokit.request . Les deux agissent de la même manière, les méthodes octokit.request octokit.rest.*
Par exemple
await octokit . rest . issues . create ( {
owner : "octocat" ,
repo : "hello-world" ,
title : "Hello, world!" ,
body : "I created this issue using Octokit!" ,
} ) ;Est le même que
await octokit . request ( "POST /repos/{owner}/{repo}/issues" , {
owner : "octocat" ,
repo : "hello-world" ,
title : "Hello, world!" ,
body : "I created this issue using Octokit!" ,
} ) ; Dans les deux cas, une demande donnée est authentifiée, repris et étranglée de manière transparente par l'instance octokit qui gère également les en-têtes accept et user-agent selon les besoins.
octokit.request peut être utilisé pour envoyer des demandes à d'autres domaines en passant une URL complète et pour envoyer des demandes aux points de terminaison qui ne sont pas (encore) documentés dans la documentation de l'API REST de GitHub.
octokit.rest Méthodes de point de terminaison Chaque point de terminaison de l'API GitHub REST a une méthode d' octokit.rest associée pour une meilleure lisibilité au code et la commodité du développeur. Voir @octokit/plugin-rest-endpoint-methods pour plus de détails.
Exemple: créez un problème
await octokit . rest . issues . create ( {
owner : "octocat" ,
repo : "hello-world" ,
title : "Hello, world!" ,
body : "I created this issue using Octokit!" ,
} ) ; Les méthodes octokit.rest Endpoint sont générées automatiquement à partir de la spécification OpenAPI de GitHub. Nous suivons les modifications de l'identification de l'identification et du paramètre afin d'implémenter les avertissements de dépréciation et de réduire la fréquence des changements de rupture.
Sous les couvertures, chaque méthode de point de terminaison est juste octokit.request avec défaut par défaut, il prend donc en charge les mêmes paramètres ainsi que l'API .endpoint() .
octokit.request() Vous pouvez appeler l'API GitHub REST directement à l'aide octokit.request . L'API request correspond à la documentation de l'API REST de GitHub 1: 1, donc tout ce que vous voyez là-bas, vous pouvez appeler en utilisant request . Voir @octokit/request pour tous les détails.
Exemple: créez un problème
L'appel API octokit.request correspondant à ce problème La documentation de la création ressemble à ceci:
// https://docs.github.com/en/rest/reference/issues#create-an-issue
await octokit . request ( "POST /repos/{owner}/{repo}/issues" , {
owner : "octocat" ,
repo : "hello-world" ,
title : "Hello, world!" ,
body : "I created this issue using Octokit!" ,
} ) ;Le 1er argument est la route API REST répertoriée dans la documentation de l'API de GitHub. Le 2ème argument est un objet avec tous les paramètres, indépendamment de leur utilisation dans le chemin, la requête ou le corps.
Tous les points de terminaison de l'API REST que Paginate renvoie les 30 premiers éléments par défaut. Si vous souhaitez récupérer tous les éléments, vous pouvez utiliser l'API de pagination. L'API de pagination s'attend à la route API REST comme premier argument, mais vous pouvez également transmettre n'importe lequel des méthodes octokit.rest.*.list* Méthodes de commodité et de meilleure lisibilité au code.
Exemple: itéré à travers tous les problèmes d'un référentiel
const iterator = octokit . paginate . iterator ( octokit . rest . issues . listForRepo , {
owner : "octocat" ,
repo : "hello-world" ,
per_page : 100 ,
} ) ;
// iterate through each response
for await ( const { data : issues } of iterator ) {
for ( const issue of issues ) {
console . log ( "Issue #%d: %s" , issue . number , issue . title ) ;
}
}L'utilisation de l'itérateur asynchronisé est le moyen le plus efficace de la mémoire d'itérer à travers tous les éléments. Mais vous pouvez également récupérer tous les articles en un seul appel
const issues = await octokit . paginate ( octokit . rest . issues . listForRepo , {
owner : "octocat" ,
repo : "hello-world" ,
per_page : 100 ,
} ) ; Les formats de type de média peuvent être définis à l'aide de mediaType: { format } sur chaque demande.
Exemple: récupérer le contenu brut d'un fichier package.json
const { data } = await octokit . rest . repos . getContent ( {
mediaType : {
format : "raw" ,
} ,
owner : "octocat" ,
repo : "hello-world" ,
path : "package.json" ,
} ) ;
console . log ( "package name: %s" , JSON . parse ( data ) . name ) ;En savoir plus sur les formats de type multimédia.
Module autonome: @octokit/request-error
Pour le traitement des erreurs de demande, importez RequestError et utilisez l'instruction try...catch .
import { RequestError } from "octokit" ; try {
// your code here that sends at least one Octokit request
await octokit . request ( "GET /" ) ;
} catch ( error ) {
// Octokit errors are instances of RequestError, so they always have an `error.status` property containing the HTTP response code.
if ( error instanceof RequestError ) {
// handle Octokit error
// error.message; // Oops
// error.status; // 500
// error.request; // { method, url, headers, body }
// error.response; // { url, status, headers, data }
} else {
// handle all other errors
throw error ;
}
} Octokit prend également en charge directement l'API GraphQL de GitHub - vous pouvez utiliser les mêmes requêtes affichées dans la documentation et disponibles dans GraphQL Explorer dans vos appels avec octokit.graphql .
Exemple: Obtenez la connexion de l'utilisateur authentifié
const {
viewer : { login } ,
} = await octokit . graphql ( `{
viewer {
login
}
}` ) ;Les variables peuvent être passées comme 2ème argument
const { lastIssues } = await octokit . graphql (
`
query lastIssues($owner: String!, $repo: String!, $num: Int = 3) {
repository(owner: $owner, name: $repo) {
issues(last: $num) {
edges {
node {
title
}
}
}
}
}
` ,
{
owner : "octokit" ,
repo : "graphql.js" ,
} ,
) ; L'API GraphQL de GitHub renvoie un maximum de 100 éléments. Si vous souhaitez récupérer tous les éléments, vous pouvez utiliser l'API de pagination.
Exemple: obtenez tous les problèmes
const { allIssues } = await octokit . graphql . paginate (
`
query allIssues($owner: String!, $repo: String!, $num: Int = 10, $cursor: String) {
repository(owner: $owner, name: $repo) {
issues(first: $num, after: $cursor) {
edges {
node {
title
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
}
` ,
{
owner : "octokit" ,
repo : "graphql.js" ,
} ,
) ;En savoir plus sur l'utilisation de la pagination GraphQL de GitHub.
Les aperçus peuvent être activés à l'aide de l'option {mediaType: previews: [] } .
Exemple: créer une étiquette
await octokit . graphql (
`mutation createLabel($repositoryId:ID!,name:String!,color:String!) {
createLabel(input:{repositoryId:$repositoryId,name:$name}) {
label: {
id
}
}
}` ,
{
repositoryId : 1 ,
name : "important" ,
color : "cc0000" ,
mediaType : {
previews : [ "bane" ] ,
} ,
} ,
) ;En savoir plus sur les aperçus du schéma GraphQL de GitHub
Le client App combine des fonctionnalités pour les applications GitHub, WebHooks et OAuth
Module autonome : @octokit/app
Pour les intégrateurs, les applications GitHub sont un moyen d'authentification et d'autorisation. Une application GitHub peut être enregistrée sur un compte d'utilisateur ou d'organisation GitHub. Un enregistrement de l'application GitHub définit un ensemble d'autorisations et d'événements WebHooks qu'il souhaite recevoir et fournit un ensemble d'identification en retour. Les utilisateurs peuvent accorder l'accès aux référentiels en les installant.
Certains points de terminaison API nécessitent que l'application GitHub s'authentifie en utilisant elle-même un jeton Web JSON (JWT). Pour les demandes affectant une installation, un jeton d'accès d'installation doit être créé à l'aide des informations d'identification de l'application et de l'ID d'installation.
Le client App s'occupe de tout cela pour vous.
Exemple: envoyez un événement de référentiel dans chaque référentiel sur lequel l'application est installée
import { App } from "octokit" ;
const app = new App ( { appId , privateKey } ) ;
for await ( const { octokit , repository } of app . eachRepository . iterator ( ) ) {
// https://docs.github.com/en/rest/reference/repos#create-a-repository-dispatch-event
await octokit . rest . repos . createDispatchEvent ( {
owner : repository . owner . login ,
repo : repository . name ,
event_type : "my_event" ,
client_payload : {
foo : "bar" ,
} ,
} ) ;
console . log ( "Event dispatched for %s" , repository . full_name ) ;
} Exemple: obtenez une instance octokit authentifiée comme une installation
const octokit = await app . getInstallationOctokit ( 123 ) ;En savoir plus sur les applications.
Module autonome : @octokit/webhooks
Lors de l'installation d'une application, les événements que les demandes d'enregistrement de l'application seront envoyés en tant que demandes à l'URL WebHook définis dans l'enregistrement de l'application.
Les demandes d'événements WebHook sont signées à l'aide du Secret WebHook, qui fait également partie de l'enregistrement de l'application. Vous devez vérifier ce secret avant de gérer la charge utile de la demande.
L' app.webhooks.* Les API fournissent des méthodes pour recevoir, vérifier et gérer les événements Webhook.
Exemple: créez un commentaire sur les nouveaux problèmes
import { createServer } from "node:http" ;
import { App , createNodeMiddleware } from "octokit" ;
const app = new App ( {
appId ,
privateKey ,
webhooks : { secret } ,
} ) ;
app . webhooks . on ( "issues.opened" , ( { octokit , payload } ) => {
return octokit . rest . issues . createComment ( {
owner : payload . repository . owner . login ,
repo : payload . repository . name ,
issue_number : payload . issue . number ,
body : "Hello, World!" ,
} ) ;
} ) ;
// Your app can now receive webhook events at `/api/github/webhooks`
createServer ( createNodeMiddleware ( app ) ) . listen ( 3000 ) ;Pour les environnements sans serveur, vous pouvez explicitement vérifier et recevoir un événement
await app . webhooks . verifyAndReceive ( {
id : request . headers [ "x-github-delivery" ] ,
name : request . headers [ "x-github-event" ] ,
signature : request . headers [ "x-hub-signature-256" ] ,
payload : request . body ,
} ) ;En savoir plus sur GitHub WebHooks.
Module autonome: @octokit/oauth-app
Les applications OAuth et les applications GitHub prennent en charge l'authentification des utilisateurs de GitHub utilisant OAuth, voir Autoriser les applications OAuth et identifier et autoriser les utilisateurs pour les applications GitHub.
Il y a quelques différences:
App est pour les applications GitHub. Si vous avez besoin de fonctionnalités spécifiques à l'application OAuth, utilisez plutôt OAuthApp .
Exemple: regardez un référentiel lorsqu'un utilisateur se connecte en utilisant le flux Web OAuth
import { createServer } from "node:http" ;
import { App , createNodeMiddleware } from "octokit" ;
const app = new App ( {
oauth : { clientId , clientSecret } ,
} ) ;
app . oauth . on ( "token.created" , async ( { token , octokit } ) => {
await octokit . rest . activity . setRepoSubscription ( {
owner : "octocat" ,
repo : "hello-world" ,
subscribed : true ,
} ) ;
} ) ;
// Your app can receive the OAuth redirect at /api/github/oauth/callback
// Users can initiate the OAuth web flow by opening /api/github/oauth/login
createServer ( createNodeMiddleware ( app ) ) . listen ( 3000 ) ; Pour les environnements sans serveur, vous pouvez échanger explicitement le code à partir de la redirection de flux Web OAuth pour un jeton d'accès. app.oauth.createToken() renvoie un objet d'authentification et émet l'événement "token.Created".
const { token } = await app . oauth . createToken ( {
code : request . query . code ,
} ) ;Exemple: Créez un jeton à l'aide du flux de l'appareil.
const { token } = await app . oauth . createToken ( {
async onVerification ( verification ) {
await sendMessageToUser (
request . body . phoneNumber ,
`Your code is ${ verification . user_code } . Enter it at ${ verification . verification_uri } ` ,
) ;
} ,
} ) ;Exemple: Créez un serveur d'applications OAuth avec des lunettes par défaut
import { createServer } from "node:http" ;
import { OAuthApp , createNodeMiddleware } from "octokit" ;
const app = new OAuthApp ( {
clientId ,
clientSecret ,
defaultScopes : [ "repo" , "gist" ] ,
} ) ;
app . oauth . on ( "token" , async ( { token , octokit } ) => {
await octokit . rest . gists . create ( {
description : "I created this gist using Octokit!" ,
public : true ,
files : {
"example.js" : `/* some code here */` ,
} ,
} ) ;
} ) ;
// Your app can receive the OAuth redirect at /api/github/oauth/callback
// Users can initiate the OAuth web flow by opening /api/oauth/login
createServer ( createNodeMiddleware ( app ) ) . listen ( 3000 ) ;Après avoir enregistré votre application GitHub, vous devez créer et déployer un serveur qui peut récupérer les demandes d'événements WebHook à partir de GitHub et accepter les redirections à partir du flux Web d'utilisateur OAuth.
La façon la plus simple de créer un tel serveur est d'utiliser createNodeMiddleware() , il fonctionne avec les deux, la méthode http.createServer() de Node ainsi qu'un middleware express.
Les itinéraires par défaut que le middleware expose sont
| Itinéraire | Description de l'itinéraire |
|---|---|
POST /api/github/webhooks | Point de terminaison pour recevoir les demandes d'événements GitHub WebHook |
GET /api/github/oauth/login | Redirige vers le point de terminaison de l'autorisation de GitHub. Accepte les paramètres de requête en option ?state et ?scopes . ?scopes est une liste séparée par des virgules de noms de portée OAuth pris en charge |
GET /api/github/oauth/callback | Le point de terminaison redirige le client. C'est là que l'événement token est déclenché |
POST /api/github/oauth/token | Échangez un code d'autorisation contre un jeton d'accès OAuth. En cas de succès, l'événement token est déclenché. |
GET /api/github/oauth/token | Vérifiez si le jeton est valide. Doit authentifier l'utilisation de jetons dans l'en-tête Authorization . Utilise POST /applications/{client_id}/token |
PATCH /api/github/oauth/token | Réinitialise un jeton (invalide actuel, renvoie un nouveau jeton). Doit authentifier l'utilisation de jetons dans l'en-tête Authorization . Utilise le point de terminaison PATCH /applications/{client_id}/token de GitHub. |
PATCH /api/github/oauth/refresh-token | Rafraîchit un jeton expirant (invalide actuel, renvoie un nouveau jeton d'accès et un jeton de rafraîchissement). Doit authentifier l'utilisation de jetons dans l'en-tête Authorization . Utilise POST https://github.com/login/oauth/access_token oauth Point. |
POST /api/github/oauth/token/scoped | Crée un jeton à portée (n'invalide pas celui actuel). Doit authentifier l'utilisation de jetons dans l'en-tête Authorization . Utilise POST /applications/{client_id}/token/scoped . |
DELETE /api/github/oauth/token | Invalide le jeton de courant, essentiellement l'équivalent d'une déconnexion. Doit authentifier l'utilisation de jetons dans l'en-tête Authorization . |
DELETE /api/github/oauth/grant | Révoque la subvention de l'utilisateur, essentiellement l'équivalent d'une désinstallation. Doit authentifier l'utilisation de jetons dans l'en-tête Authorization . |
Exemple: créez un serveur GitHub avec express
import express from "express" ;
import { App , createNodeMiddleware } from "octokit" ;
const expressApp = express ( ) ;
const octokitApp = new App ( {
appId ,
privateKey ,
webhooks : { secret } ,
oauth : { clientId , clientSecret } ,
} ) ;
expressApp . use ( createNodeMiddleware ( app ) ) ;
expressApp . listen ( 3000 , ( ) => {
console . log ( `Example app listening at http://localhost:3000` ) ;
} ) ; Vous ne devez pas exposer le secret client de votre application à l'utilisateur, vous ne pouvez donc pas utiliser le constructeur App . Au lieu de cela, vous devez créer un serveur à l'aide du constructeur App qui expose les routes /api/github/oauth/* , à travers lesquelles vous pouvez implémenter en toute sécurité une connexion OAuth pour les applications exécutées dans un navigateur Web.
Si vous définissez (User) Authorization callback URL à votre propre application, vous devez lire les paramètres ?code=...&state=... , comparez le paramètre state à la valeur renvoyée par app.oauthLoginUrl() plus tôt pour protéger contre les attaques contre la contrefaçon, puis échangez le code contre un jeton d'autorisation OAuthAut.
Si vous exécutez un serveur d'applications comme décrit ci-dessus, l'itinéraire par défaut pour le faire est POST /api/github/oauth/token .
Une fois que vous avez récupéré avec succès le jeton, il est également recommandé de supprimer le ?code=...&state=... Requête paramètres de l'URL du navigateur
const code = new URL ( location . href ) . searchParams . get ( "code" ) ;
if ( code ) {
// remove ?code=... from URL
const path =
location . pathname +
location . search . replace ( / b(code|state)=w+ / g , "" ) . replace ( / [?&]+$ / , "" ) ;
history . replaceState ( { } , "" , path ) ;
// exchange the code for a token with your backend.
// If you use https://github.com/octokit/oauth-app.js
// the exchange would look something like this
const response = await fetch ( "/api/github/oauth/token" , {
method : "POST" ,
headers : {
"content-type" : "application/json" ,
} ,
body : JSON . stringify ( { code } ) ,
} ) ;
const { token } = await response . json ( ) ;
// `token` is the OAuth Access Token that can be use
const { Octokit } = await import ( "https://esm.sh/@octokit/core" ) ;
const octokit = new Octokit ( { auth : token } ) ;
const {
data : { login } ,
} = await octokit . request ( "GET /user" ) ;
alert ( "Hi there, " + login ) ;
} ? Nous travaillons sur @octokit/auth-oauth-user-client pour fournir une API simple pour toutes les méthodes liées aux jetons utilisateur OAuth.
Le plan consiste à ajouter une nouvelle route GET /api/github/oauth/octokit.js vers le middleware de nœud qui renverra un fichier javascript qui peut être importé dans un fichier html. Il mettra une instance octokit pré-authentifiée disponible.
Module autonome: @octokit/action
? Un client Action à part entière est en attente. Vous pouvez utiliser @actions/github pour le moment
Mit
