libgfi

libgfi

Un módulo a los problemas de GitHub de superficie etiquetados como "buen primer problema" (y variantes similares) para cualquier organización de Github, repositorio o proyecto predefinido.

Requisitos previos

Para usar un buen primer problema, deberá tener algunas cosas instaladas:

• Node.js 8.0.0 o superior
  • Si necesita instalar Node.js, puede descargarlo desde la página de descargas oficiales
  • Si desea usar un administrador de versiones dinámico, puede usar algo como NVM en MacOS, Linux y WSL.
• NPM 5.0.0 o superior
  • Si ya tiene Node.js 8.0.0 o superior, tendrá NPM 5.0.0 o superior.
  • Si necesita actualizar su CLI NPM, ejecute npm i -g npm

Uso

Instalación:

npm install libgfi

Un ejemplo de cómo se puede usar libgfi en una aplicación node.js:

 const gfi = require ( 'libgfi' )

let log = async ( ) => {
  let issues = await gfi ( 'microsoft' ) // search the 'microsoft' GitHub organization
  issues . forEach ( function ( issue ) {
    console . log ( '#' + issue . pr + ': ' + issue . title )
  } )
}

log ( )

Buscar un repositorio específico:

 const gfi = require ( 'libgfi' )

gfi ( 'golang/dep' )
  . then ( ( issues ) => {
    console . log ( issues )
  } )
  . catch ( ( error ) => {
    console . error ( error )
  } )

Pasando en un conjunto personalizado de organizaciones para buscar:

 const gfi = require ( 'libgfi' )

const options = {
  projects : {
    node : {
      name : 'Node.js' , // Human readable name
      q : 'org:nodejs is:issue is:open label:"good first issue"' , //GitHub search query
      description : "Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine." // Human readable description
    }
  }
}

let log = async ( ) => {
  console . log ( await goodFirstIssue ( 'node' , options ) ) // search the 'node' property
}

log ( )

Pasar las credenciales de GitHub (ver la documentación de autenticación de Octokit para obtener más detalles) para que la autenticación aumente exponencialmente el límite de tasa:

 const gfi = require ( 'libgfi' )

const options = {
  auth : '<replace_with_your_github_secret_personal_access_token>' // or username/password + 2fa, or app installation access token
}

let log = async ( ) => {
  let issues = await gfi ( 'microsoft' , options ) // search the 'microsoft' GitHub organization
  issues . forEach ( function ( issue ) {
    console . log ( '#' + issue . pr + ': ' + issue . title )
  } )
}

log ( )

Ejemplos

El buen primer problema tiene un ejemplo/ directorio, en el que intentamos mantener varios ejemplos de cómo se puede usar un buen primer problema como módulo. Si desea contribuir a los ejemplos, ¡no dude en enviar un PR! ?

Agregar nuevos proyectos: más información

¡Puede extraer sus consultas directamente de una búsqueda estándar de GitHub! Si desea crear algo un poco más complejo, puede usar la herramienta de búsqueda avanzada si desea crear consultas personalizadas más específicas: https://github.com/search/advanced

Como CLI, good-first-issue utiliza el marco CLI Commander.js. Si desea comprender mejor cómo se construye nuestra CLI, Commander.js está bastante bien documentado. También se utilizan tiza para colorear terminal y boxen para simplificar la implementación del contenedor de salida.

Proceso de lanzamiento

Un buen primer problema sigue un proceso de liberación relativamente estricto destinado a garantizar los flujos de especias.

Versiones

Versión semántica	Tipo	Razón
Mayor ( x .xx)	Rompiendo cambios y actualizaciones no triviales	Asegurar que los usuarios finales puedan confiar en un buen primer problema, no romperlo, sin embargo, lo están consumiendo
Menor (x. X .x)	Adiciones de proyecto, otras adiciones de características	Siguiendo el estándar Semver, las adiciones de proyectos y adiciones de características son mejoras compatibles con versiones al revés. Generalmente intentamos enviar una adición por menor.
Parche (xx x )	Correcciones de errores, mejoras menores a metadatos y contenido	Pequeñas soluciones apenas visibles para mejorar UX/DX o arreglar el módulo

Etiquetas e hitos

Utilizamos tanto las etiquetas como los hitos para rastrear los lanzamientos. Dado que las adiciones del proyecto cuentan como un lanzamiento menor, preferimos espaciarlos y enviarlos individualmente en lugar de enviar a muchos a la vez. Este ritmo puede revisarse más tarde, pero por ahora, presenta la necesidad de una cola de lanzamiento y establecer cosas para ser lanzadas por delante de ellos que realmente sean lanzados.

Utilizamos la etiqueta de cola de lanzamiento y el hito para hacer cola PRS que se han revisado y están listos para ser lanzados.

Una vez que un PR esté listo para ser lanzado, se agregará un hito que se correlaciona con la versión de Semver en la que se lanzará. Idealmente, esto eventualmente se usará para el seguimiento de ChangeLog, pero por ahora es una buena manera de mantenerse organizado. Para mantener las cosas ordenadas, una vez que una nueva versión haya enviado el hito se cerrará.

Que contribuye

Si está interesado en solucionar problemas y contribuir directamente a la base de código, consulte el documento que contribuye.md