Transbank SDK Node.js

Este es el SDK oficial de Transbank para Node.js

$3

- Node.js 18+

$3

Puedes instalar SDK en tu proyecto usando NPM

``bash
npm install transbank-sdk
`

$3

ó también instalarlo usando Yarn

`bash
yarn add transbank-sdk
`

$3

`bash


Este comando te permite ver las vulnerabilidades

npm audit

Este comando te permite reparar las vulnerabilidades

npm audit fix
`

$3

`bash
npm run build
`

$3

`bash
npm run test

Tests con coverage


npm run test:coverage
`

Documentación

Puedes encontrar toda la documentación de cómo usar este SDK en el sitio www.transbankdevelopers.cl.

La documentación relevante para usar este SDK es:

- Documentación general sobre los productos y sus diferencias:
Webpay.
- Documentación sobre ambientes, deberes del comercio, puesta en producción,
etc.
- Primeros pasos con Webpay.
- Referencia detallada sobre Webpay

Información para contribuir a este proyecto

$3

- Para los mensajes de commits, nos basamos en las Git Commit Guidelines de Angular.
- Usamos inglés para los nombres de ramas y mensajes de commit.
- Los mensajes de commit no deben llevar punto final.
- Los mensajes de commit deben usar un lenguaje imperativo y estar en tiempo presente, por ejemplo, usar "change" en lugar de "changed" o "changes".
- Los nombres de las ramas deben estar en minúsculas y las palabras deben separarse con guiones (-).
- Todas las fusiones a la rama principal se deben realizar mediante solicitudes de Pull Request(PR). ⬇️
- Se debe emplear tokens como "WIP" en el encabezado de un commit, separados por dos puntos (:), por ejemplo, "WIP: this is a useful commit message".
- Una rama con nuevas funcionalidades que no tenga un PR, se considera que está en desarrollo.
- Los nombres de las ramas deben comenzar con uno de los tokens definidos. Por ejemplo: "feat/tokens-configurations".

$3

WIP = En progreso.

feat = Nuevos features.

fix = Corrección de un bug.

docs = Cambios solo de documentación.

style = Cambios que no afectan el significado del código. (espaciado, formateo de código, comillas faltantes, etc)

refactor = Un cambio en el código que no arregla un bug ni agrega una funcionalidad.

perf = Cambio que mejora el rendimiento.

test = Agregar test faltantes o los corrige.

chore = Cambios en el build o herramientas auxiliares y librerías.

revert = Revierte un commit.

release = Para liberar una nueva versión.

$3

- El PR debe estar enfocado en un cambio en concreto, por ejemplo, agregar una nueva funcionalidad o solucionar un error, pero un solo PR no puede agregar una nueva funcionalidad y arreglar un error.
- El título del los PR y mensajes de commit no debe comenzar con una letra mayúscula.
- No se debe usar punto final en los títulos.
- El título del PR debe comenzar con el short lead token definido para la rama, seguido de ":"" y una breve descripción del cambio.
- La descripción del PR debe detallar los cambios que se están incorporando.
- La descripción del PR debe incluir evidencias de que los test se ejecutan de forma correcta o incluir evidencias de que los cambios funcionan y no afectan la funcionalidad previa del proyecto.
- Se pueden agregar capturas, gif o videos para complementar la descripción o demostrar el funcionamiento del PR.

#### Flujo de trabajo

1. Crea tu rama desde develop.
2. Haz un push de los commits y publica la nueva rama.
3. Abre un Pull Request apuntando tus cambios a develop.
4. Espera a la revisión de los demás integrantes del equipo.
5. Para poder mezclar los cambios se debe contar con 2 aprobaciones de los revisores y no tener alertas por parte de las herramientas de inspección.

$3

!gitflow

Generar una nueva versión

Para generar una nueva versión, se debe crear un PR (con un título "release: prepare release X.Y.Z" con los valores que correspondan para X, Y y Z). Se debe seguir el estándar SemVer para determinar si se incrementa el valor de X (si hay cambios no retrocompatibles), Y (para mejoras retrocompatibles) o Z (si sólo hubo correcciones a bugs).

En ese PR deben incluirse los siguientes cambios:

1. Modificar el archivo CHANGELOG.md para incluir una nueva entrada (al comienzo) para X.Y.Z que explique en español los cambios.
2. Actualizar README.md en caso de que se requiera. Validar si cambiaron instrucciones o requerimientos.
3. Modificar el archivo package.json y modificar la versión.

Luego de obtener aprobación del PR, debe mezclarse a master e inmediatamente generar un release en GitHub con el tag X.Y.Z`. En la descripción del release debes poner lo mismo que agregaste al changelog.

Posterior a la liberación debes mezclar la rama release en develop, finalmente realizar un rebase de la rama develop utilizando como base la rama main.