Glosario

• 📝 Requerimientos básicos
• 🙌 Let's start
• 📦 Instalar dependencias
• 💻 Scripts
• 🛠️ Build and Publish
• 🔀 Workflows
• 📤 Commits
• 📄 Changelog
• 📜 License MIT

💬 Este repositorio cuenta con una configuración base para GitHub Actions, Codecov y SonarCloud, las cuales se pueden remover fácilmente del proyecto o bien, terminar de configurarlas para aprovechar al maximo las buenas prácticas.

📝 Requerimientos básicos

• Node.js v14.15.4 or higher (Download)
• NPM v6.14.10 or higher
• NestJS v8.2.0 or higher (Documentación)
• Cuenta en NPM y/o YARN

🙌 Let's start

Con el botón Use this template, creamos un repositorio nuevo en nuestro GitHub copiando todos los archivos del repositorio original, y luego hacemos un git clone del mismo.

También podés ejecutar el siguiente script cambiando el nombre de destino

git clone https://github.com/rudemex/nestjs-package-starter.git <nombre-de-destino>

Example:

git clone https://github.com/rudemex/nestjs-package-starter.git my-awesome-package

Una vez clonado el repositorio, tenemos que cambiar el name del archivo package.json, ya que este va a ser el nombre del paquete a generar y la version la ponemos al valor inicial.

{
  ...,
  "name": "nestjs-package-starter",
  "version": "x.x.x",
  ...
  "name": "my-awesome-package",
  "version": "0.0.1",
  ...
}

💬 También podés ajustar otras propiedades como el author, description, keywords, etc.

📦 Instalar dependencias

Estando en la carpeta del proyecto, instalamos sus dependencias con el script.

 npm install

💻 Scripts

Inicia los test con coverage

npm run test

Eslintea el código

npm run lint

Realiza el build del paquete

Los builds se hacen con una herramienta llamada @pika/pack que por debajo usa rollup, una vez que el build se realizó, vas a encontrar el contenido generado en la carpeta ./pkg que contiene los diferentes builds, hasta el package.json con las referencias a los módulos generados.

npm run build

Para probar localmente el paquete antes de publicarlo, podés utilizar el comando npm link estando dentro de la carpeta ./pkg, y luego linkearlo en tu proyecto para probarlo. más info

cd ./pkg
npm link

npm link <name-of-package-json>

npm unlink <name-of-package-json>

Realiza el build del paquete y actualiza la version.

npm version <tag>
// npm version v1.2.3

Publicar paquete

npm publish

🛠️ Build and Publish

Existen varias maneras para publicar el paquete en npm.

Sencilla y rápida

La manera más sencilla y rápida de publicar el paquete es ejecutar el script de build y luego ir dentro de la carpeta ./pkg y ejecutar el script de publish.

npm run build
cd ./pkg
npm publish

💬 Podés reemplazar npm publish por yarn publish, y publicar el paquete tanto en npm como yarn

La manera más óptima

Consiste en ejecutar el script de version con el tag correspondiente a desplegar, siguiendo la sintaxis de versionado. Con esta forma, se actualiza automáticamente la version del package.json, y solo queda pushear al repositorio los cambios generados.

npm version v1.0.1
cd ./pkg
npm publish

git push

Automatizada

En la carpeta .github/workflows se encuentra los procesos automatizados para GitHub Actions, en esta se encuentra el pipeline para el publish, el cual realiza todos los pasos correspondientes de manera automatizada para compilar el paquete, publicarlo y versionar el repositorio con solo seleccionar el tipo de version a desplegar, pero para poder utilizar este método, es importante configurar los workflows que se detalla a continuación.

🔀 Workflows (GitHub Actions)

Para poder hacer uso de los workflows que contiene este repositorio, primero debes generar los tokens correspondientes, o bien eliminar los procesos de los mismos.

En los siguientes links, vas a encontrar toda la documentación para obtener los tokens de cada aplicación, que luego tendrás que configurarlo en los secrets en el repositorio. Configurar Secret

Secrets

• GH_EMAIL GitHub User Email
• GH_TOKEN Documentación GitHub
• NPM_TOKEN Documentación NPM
• CODECOV_TOKEN Documentación Codecov.io
• SONAR_TOKEN Documentación SonarCloud

📤 Commits

Para los mensajes de commits se toma como referencia conventional commits.

<type>[optional scope]: <description>

[optional body]

[optional footer]

• type: chore, docs, feat, fix, refactor (más comunes)
• scope: indica la página, componente, funcionalidad
• description: comienza en minúsculas y no debe superar los 72 caracteres.

📄 Changelog

All notable changes to this project will be documented in Changelog file.