Forem: hijuliancode

Crear un Paquete de NPM - Paso a Paso / TypeScript, commit linting, Husky, Semantic Release

hijuliancode — Fri, 13 Sep 2024 04:27:47 +0000

¡Hola!

Hoy traigo una guía para configurar un paquete de JavaScript/NPM desde cero, incluyendo la configuración de commit linting, Husky y semantic release para un proceso de desarrollo y publicación más fluido. ¡Vamos a ello!

Demo

Crear un nuevo directorio para el proyecto:

   mkdir nuevo-proyecto
   cd nuevo-proyecto

Inicializar un repositorio Git:

   git init

Crear un archivo .gitignore para excluir node_modules:

   echo "node_modules" > .gitignore

Inicializar un nuevo proyecto de Node.js:

   npm init -y

Asegúrate de agregar "type": "module" en tu package.json para habilitar módulos ES6.

Configurar commitlint para imponer mensajes de commits consistentes:

   npm install --save-dev @commitlint/{cli,config-conventional}
   echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

Configurar husky para garantizar que los commits sigan las reglas de commitlint:

   npm install --save-dev husky
   npx husky init
   rm .husky/pre-commit
   echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

Verificar la configuración de commitlint:

   npx commitlint --from HEAD~1 --to HEAD --verbose

Hacer algunos commits de prueba para verificar la configuración:

   git add .
   git commit -m "foo: este commit fallará" # Este commit debería fallar
   git commit -m "chore: este commit pasará" # Este commit debería pasar

Instalar y configurar semantic-release para versionado y publicaciones automáticas:

   npm install --save-dev semantic-release
   npm install @semantic-release/git @semantic-release/changelog -D

Crear los directorios y el archivo necesarios para semantic-release:

   mkdir .github
   mkdir .github/workflows/
   touch .github/workflows/release.yml

Taguear el último commit y subirlo al repositorio:

git log # Copiar el GUID del último commit
git tag v0.0.0 <COMMIT_GUID>
git tag --contains <COMMIT_GUID>
git push origin tag v0.0.0

Crear un nuevo token de NPM y agregarlo a los secretos de tu repositorio.

Instalar y configurar Commitizen para mensajes de commit consistentes:

npm install commitizen -g
commitizen init cz-conventional-changelog --save-dev --save-exact

Instalar herramientas adicionales de desarrollo como TypeScript, Jest y Rollup:

npm install --save-dev typescript @types/node jest ts-jest @types/jest
npm install --save-dev rollup @rollup/plugin-typescript @rollup/plugin-terser
npm install --save-dev rollup-plugin-dts

Crear el archivo de configuración de Rollup (rollup.config.js):

import terser from '@rollup/plugin-terser';
import typescript from '@rollup/plugin-typescript';
import dts from 'rollup-plugin-dts';

export default [
  {
    input: 'src/index.ts',
    plugins: [
      typescript({ 
        tsconfig: './tsconfig.json',
        declaration: false,
        declarationDir: null,
      }),
      terser()
    ],
    output: [
      {
        file: 'dist/index.mjs',
        format: 'esm',
      },
      {
        file: 'dist/index.cjs',
        format: 'cjs',
        exports: 'named',
      },
    ]
  },
  {
    input: 'src/index.ts',
    plugins: [dts()],
    output: {
      file: 'dist/index.d.ts',
      format: 'es',
    },
  }
];

¡Y eso es todo! Ahora tienes un proyecto completamente configurado y listo para desarrollar y publicar tu librería JavaScript. Si tienes alguna pregunta o necesitas más ayuda, no dudes en preguntar. ¡Feliz codificación! 🚀

Saludos.

Pendiente:
[] Explicar creacion de tokens e instalacion en githun
[] Actualizacion de package.json con husky y demas

Effective Git Workflow: Managing Version Control in Team Environments

hijuliancode — Fri, 13 Sep 2024 04:21:04 +0000

Git is a version control system used to manage changes to files, typically in code or design projects.

What is Version Control?

Version control refers to managing changes made to files over time. It allows us to:

Track modifications,
Revert to previous versions,
Collaborate effectively.

Why do we use Git?

Git helps us:

Preserve changes,
Track modifications across one or multiple files,
Save progress in projects, whether code or design.

While Git can be used for personal notes or academic purposes, it's mainly used for team collaboration. Simply put, Git is "a tool that helps me organize with my team and track the work we do."

Remember, Git operates within a directory, so even if you want to track a single file, Git must be initialized in the directory containing that file.

Useful Commands for Team Collaboration

# Initialize a Git repository in a directory
git init

# Update all remote branches
git fetch --all

# List local branches
git branch

# List both local and remote branches
git branch -a

# Add a remote repository
git remote add origin https://gitlab.com/hijuliancode/demo-git-tutorial

# Add a Heroku remote repository
git remote add heroku https://git.heroku.com/demo-heroku-repo.git

# Remove a remote repository
git remote remove heroku

# View all configured remote repositories
git remote -v

# Fetch and merge changes from the master branch of the remote repository
git pull origin master

# Push changes from the local master branch to the remote repository
git push origin master

# Display the state of your working directory and staging area
git status

# Stage a file for commit
git add filename.html

# Stage all changes in the current directory for commit
git add .

# Remove a file from the staging area
git reset filename.html

# Remove all changes from the staging area
git reset .

# Rename a file
git mv oldname.js newname.js

# Rename a file within a directory
git mv folder/oldname.js folder/newname.js

# Temporarily save changes and revert to the last commit
git stash

# Restore changes from the stash
git stash apply

# Create a commit with a descriptive message
git commit -m "Message"

Example Workflow

Imagine we’re building a house as a project. Here’s how a workflow might look with three team members: Person A, Person B, and Person C.

Person A initializes the repository:

git init
git remote add origin git@gitlab.com:hijuliancode/demo-git-tutorial.git

Person A creates an initial file and pushes it to the repository:

echo "## demo-git-tutorial" >> README.md
git add README.md
git commit -m "initial commit"
git branch -M master
git push origin master

Person B and Person C clone the repository:

git clone git@gitlab.com:hijuliancode/demo-git-tutorial.git
cd demo-git-tutorial

Person A creates the develop branch and pushes it to the remote:
```
git checkout -b develop
git push origin develop
```
Person B and Person C update their local repositories to include the develop branch:
```
git fetch --all
git checkout develop
```

Now everyone has the repository and can start contributing.

Person A creates a feature branch to work on the house plans:

git checkout -b feature/house-plans
touch house-plans.js
git add house-plans.js
git commit -m "Add house plans"
git push origin feature/house-plans

Person B and Person C update their local repositories to access the new branch:
```
git fetch --all
git branch -a
git checkout feature/house-plans
```
Person B wants to suggest improvements to the house plans. They can do so by creating a Pull Request (or Merge Request):
- Navigate to the repository's GitHub or GitLab page,
- Go to the Pull Request or Merge Request section,
- Assign a reviewer (like a team lead or peer).

To apply the suggested changes:

   git add house-plans.js
   git commit -m "Improve house plans"
   git push origin feature/house-plans

Once the feature branch is reviewed and merged, it can be deleted:

git checkout develop
git pull origin develop
git branch -D feature/house-plans

Repeat this process for new features or changes!

Create a NPM Package - Step by Step / TypeScript, commit linting, Husky, Semantic Release

hijuliancode — Fri, 13 Sep 2024 04:02:49 +0000

Hello, developer community!

Today, I’m going to walk you through the steps to set up a JavaScript library from scratch, including configuring commit linting, Husky, and semantic release for smooth development and release processes. Let’s dive into it!

Demo

Create a new project directory:

   mkdir new-project
   cd new-project

Initialize a Git repository:

   git init

Create a .gitignore file to exclude node_modules:

   echo "node_modules" > .gitignore

Initialize a new Node.js project:

   npm init -y

Make sure to add "type": "module" to your package.json to enable ES6 modules.

Set up commitlint to enforce consistent commit messages:

   npm install --save-dev @commitlint/{cli,config-conventional}
   echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

Configure husky to ensure commits follow commitlint rules:

   npm install --save-dev husky
   npx husky init
   rm .husky/pre-commit
   echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

Verify commitlint configuration:

   npx commitlint --from HEAD~1 --to HEAD --verbose

Perform some test commits to check the configuration:

   git add .
   git commit -m "foo: this will fail" # This commit should fail
   git commit -m "chore: this will pass" # This commit should pass

Install and configure semantic-release for automated versioning and releases:

   npm install --save-dev semantic-release
   npm install @semantic-release/git @semantic-release/changelog -D

Create the necessary directories and file for semantic-release:

   mkdir .github
   mkdir .github/workflows/
   touch .github/workflows/release.yml

Tag the latest commit and push it to the repository:

git log # Copy the GUID of the latest commit
git tag v0.0.0 <COMMIT_GUID>
git tag --contains <COMMIT_GUID>
git push origin tag v0.0.0

Create a new NPM token and add it to your repository secrets.

Install and configure Commitizen for consistent commit messages:

npm install commitizen -g
commitizen init cz-conventional-changelog --save-dev --save-exact

Install additional development tools like TypeScript, Jest, and Rollup:

npm install --save-dev typescript @types/node jest ts-jest @types/jest
npm install --save-dev rollup @rollup/plugin-typescript @rollup/plugin-terser
npm install --save-dev rollup-plugin-dts

Create the Rollup configuration file (rollup.config.js):

import terser from '@rollup/plugin-terser';
import typescript from '@rollup/plugin-typescript';
import dts from 'rollup-plugin-dts';

export default [
  {
    input: 'src/index.ts',
    plugins: [
      typescript({ 
        tsconfig: './tsconfig.json',
        declaration: false,
        declarationDir: null,
      }),
      terser()
    ],
    output: [
      {
        file: 'dist/index.mjs',
        format: 'esm',
      },
      {
        file: 'dist/index.cjs',
        format: 'cjs',
        exports: 'named',
      },
    ]
  },
  {
    input: 'src/index.ts',
    plugins: [dts()],
    output: {
      file: 'dist/index.d.ts',
      format: 'es',
    },
  }
];

And that’s it! You now have a fully configured project ready for developing and publishing your JavaScript library. If you have any questions or need further assistance, feel free to ask. Happy coding! 🚀

Best regards!

Flujo de trabajo Git eficaz: gestión del control de versiones en entornos de equipo

hijuliancode — Sun, 17 Jan 2021 04:32:02 +0000

Git: Un Sistema de Control de Versiones

Git es un sistema de control de versiones utilizado para gestionar cambios en archivos, generalmente en proyectos de código o diseño.

¿Qué es el Control de Versiones?

Se refiere a la administración de cambios realizados a archivos a lo largo del tiempo. Nos permite:

Rastrear modificaciones,
Revertir a versiones anteriores,
Colaborar de manera efectiva.

¿Por qué usamos Git?

Git nos ayuda a:

Preservar cambios,
Rastrear modificaciones en uno o más archivos,
Guardar el progreso en proyectos, ya sean de código o diseño.

Aunque Git también se puede usar para notas personales o tareas académicas, su uso principal es para colaboración en equipo. En términos simples, Git es "una herramienta que me ayuda a organizarme con mi equipo y a seguir el trabajo que hacemos".

Recuerda que Git opera dentro de un directorio. Si quieres rastrear un solo archivo, Git debe estar inicializado en el directorio que contiene ese archivo.

Comandos Útiles para Colaboración en Equipo

# Inicializar un repositorio Git en un directorio
git init

# Actualizar todas las ramas remotas
git fetch --all

# Listar ramas locales
git branch

# Listar ramas locales y remotas
git branch -a

# Agregar un repositorio remoto
git remote add origin https://gitlab.com/hijuliancode/demo-git-tutorial

# Agregar un repositorio remoto de Heroku
git remote add heroku https://git.heroku.com/demo-heroku-repo.git

# Eliminar un repositorio remoto
git remote remove heroku

# Ver todos los repositorios remotos configurados
git remote -v

# Traer y fusionar cambios del repositorio remoto en la rama master
git pull origin master

# Subir cambios desde la rama master local al repositorio remoto
git push origin master

# Mostrar el estado del directorio de trabajo y el área de staging
git status

# Agregar un archivo al área de staging
git add filename.html

# Agregar todos los cambios del directorio actual al área de staging
git add .

# Quitar un archivo del área de staging
git reset filename.html

# Quitar todos los archivos del área de staging
git reset .

# Renombrar un archivo
git mv oldname.js newname.js

# Renombrar un archivo dentro de un directorio
git mv folder/oldname.js folder/newname.js

# Guardar temporalmente los cambios y volver al último commit
git stash

# Restaurar los cambios guardados en el stash
git stash apply

# Crear un commit con un mensaje descriptivo
git commit -m "Mensaje"

Ejemplo de Workflow

Imagina que estamos construyendo una casa como proyecto. Aquí te dejo el flujo de trabajo que usarían tres personas: Persona A, Persona B y Persona C.

Persona A inicializa el repositorio:

git init
git remote add origin git@gitlab.com:hijuliancode/demo-git-tutorial.git

Persona A crea un archivo inicial y lo empuja al repositorio:

echo "## demo-git-tutorial" >> README.md
git add README.md
git commit -m "initial commit"
git branch -M master
git push origin master

Persona B y Persona C clonan el repositorio:

git clone git@gitlab.com:hijuliancode/demo-git-tutorial.git
cd demo-git-tutorial

Persona A crea la rama develop y la sube al repositorio remoto:
```
git checkout -b develop
git push origin develop
```
Persona B y Persona C actualizan sus repositorios locales para incluir la rama develop:
```
git fetch --all
git checkout develop
```

Ahora, todos tienen el repositorio y pueden empezar a contribuir.

Persona A crea una rama de característica (feature) para trabajar en los planos de la casa:

git checkout -b feature/house-plans
touch house-plans.js
git add house-plans.js
git commit -m "Add house plans"
git push origin feature/house-plans

Persona B y Persona C actualizan sus repositorios locales para obtener la nueva rama:
```
git fetch --all
git branch -a
git checkout feature/house-plans
```
Persona B sugiere mejoras a los planos. Para eso crea un Pull Request (o Merge Request):
- Ve al repositorio en GitHub o GitLab,
- Navega a la sección de Pull Requests o Merge Requests,
- Asigna un revisor (como un líder de equipo o un compañero).

Para aplicar las sugerencias:

   git add house-plans.js
   git commit -m "Improve house plans"
   git push origin feature/house-plans

Una vez que se aprueba y fusiona la rama, puede eliminarse:

git checkout develop
git pull origin develop
git branch -D feature/house-plans

¡Y listo! Repite este proceso para nuevas características o cambios.