DEV Community: Alberto Chamorro

TypeScript [Capítulo 1] ¿Qué es TypeScript? Instalación y tipos básicos

Alberto Chamorro — Fri, 15 Jul 2022 09:54:09 +0000

Si has trabajado con JavaScript sabrás que es considerado un lenguaje de tipado débil o no tipado.

En aplicaciones pequeñas puede que esto no sea un problema pero en un entorno empresarial donde el negocio y las aplicaciones tienden a escalar, dónde se busca estabilidad y solidez del software y donde el equipo de desarrollo incluyen a varias personas o incluso varios equipos los errores desconocidos empiezan a aparecer.

¿Qué es TypeScript?

TypeScript (https://www.typescriptlang.org/) es un lenguaje de programación open-source de tipado fuerte basado en JavaScript creado por Microsoft (podéis ver su repositorio de código en GitHub).

Su uso cada vez es más extendido frente a JavaScript ya que nos trae lo mejor de los lenguajes de programación orientados a objetos para ayudarnos a modelar nuestras entidades. Su sintaxis es idéntica pero con añadidos, por eso también escucharás que es considerado un superset de tipos de JavaScript.

Sus herramientas más potentes son el linter y el compilador ya que son capaces de detectar errores en tiempo de desarrollo y compilación. Tras el proceso de compilación, el código final será JavaScript puro compilado a la versión de ECMAScript que indiquemos en la configuración.

TypeScript vs JavaScript

Imagina una función en JavaScript para sumar dos números:

function sum(firstNumber, secondNumber) {
  return firstNumber + secondNumber
}

sum(1, 2) // Resultado: 3

Aparentemente todo correcto ¿verdad? Ahora vamos a llamar más veces a la función:

sum(1, "2") // 12
sum("1", "2") // 12
sum(1) // NaN
sum(true, false) // 1
sum([2, 4], [6, 8]) // '2,46,8'

Obviamente el ejemplo es exagerado pero podría ocurrir. El problema es que estos errores se detectan en tiempo de ejecución por lo que siempre llegamos tarde.

Otro caso de error es la mutabilidad de los tipos. Ahora mismo JavaScript permite sin problemas algo como:

let id = 12
id = "A-12"
id = true
console.log(id) // true

Ahora imagina que pudieras decirle a la variable id que tiene que ser un número:

let id: number = 12
id = "A-12" // TS2322: Type 'string' is not assignable to type 'number'

El código anterior daría error al compilar además de que tu editor te avisará marcando la línea con error.

Volvemos al ejemplo de la función pero con tipos:

function sum(firstNumber: number, secondNumber: number) {
  return firstNumber + secondNumber
}

sum(1, 2) // Resultado: 3

const texto = "12"
sum(1, texto) // TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

Tendremos un error en tiempo de desarrollo y compilación indicándote que estás intentando utilizar un 'string' cuando la función necesita un 'number'.

¡Quiero empezar! ¿Cómo lo instalo?

La mayor parte de los frameworks/librerías en su documentación tienen información con comandos específicos para crear un proyecto desde cero o añadir TypeScript a un proyecto existente.

Un ejemplo sería la documentación de React (https://create-react-app.dev/docs/adding-typescript/):

npx create-react-app my-app --template typescript

Con el comando anterior iniciaremos un nuevo proyecto de React con TypeScript instalado y configurado.

Otros frameworks como Angular o NestJS trabajan con TypeScript por defecto y no tendremos que hacer nada especial.

Aun así, si quieres hacerlo manualmente teniendo un proyecto de npm bastaría con seguir dos sencillos pasos:

1- Instalar el paquete typescript como dependencia de desarrollo:

npm install --save-dev --save-exact typescript

// Version reducida
npm i -DE typescript

2- Inicializar el proyecto de TypeScript:

npx tsc --init

Este paso generará el fichero tsconfig.json en la raíz del proyecto.
Este fichero es el fichero de configuración que necesita el compilador de TypeScript, hablaré de él en un capítulo posterior.

Sólo nos quedaría añadir un script a nuestro fichero package.json para poder compilar:

"scripts": {
  "build": "tsc --build",
  "start": "tsc --watch" // Modo observador para compilar automáticamente cuando se modifiquen los ficheros
},

Ya podríamos crear nuestro primer fichero TypeScript, por ejemplo index.ts en nuestro proyecto y compilarlo.
Como puedes ver, el fichero lleva la extensión .ts específica de TypeScript.

Ahora prueba a meter el siguiente código y ejecutar npm run build:

function sayHello(name: string): string {
  return `Hola ${name}`
}

console.log(sayHello("Pedro"))

El compilador generará el fichero index.js que podrás ejecutar con node index.js.

¿Y tengo que hacer todo esto sólo para las pruebas? Pues no. En la web de TypeScript tienes su playground (https://www.typescriptlang.org/play) dónde puedes hacer pruebas, ver el código compilado en JavaScript, ejecutarlo, etc

El fichero tsconfig.json es el fichero de configuración utilizado por el compilador de TypeScript

Tipado o type annotations

Como has podido comprobar en los ejemplos anteriores, definir el tipo de una variable o propiedad es tan sencillo como escribir : seguido del tipo que queramos que tenga, por ejemplo:

let id: number = 12 // La variable id es de tipo número

Lo mismo ocurre con las funciones, donde podremos indicar los tipos tanto para la entrada como para la salida:

function sayHello(name: string): string {
  return `Hola ${name}`
}

En la función anterior puedes ver que el tipo de retorno de la función será un string y se indica después de la lista de parámetros.

Inferencia de tipos

En ocasiones no es necesario explícitamente añadir una anotación con el tipo de una propiedad, por ejemplo cuando inicializamos la variable con un valor.

En este caso, TypeScript es capaz de determinar el tipo dependiendo del valor que le estemos dando inicialmente. A esto se le conoce como inferencia de tipos.

let id = true // id es un boolean
id = 0 // TS2322: Type 'number' is not assignable to type 'boolean'.

Tipos básicos

Hay una gran cantidad de tipos, desde los más básicos como string o number hasta algunos más complejos como interfaces, genéricos, union types, literal types, ...

Vamos a repasar los tipos básicos, los que ya nos trae JavaScript.

// String
const name: string = 'Alberto'
const surname: string = "Chamorro"
const fullName: string = `${name} ${surname}`

// Number
const age: number = 33
const price: number = 33.5
const hexadecimal: number = 0xf00d

// Boolean
const isTrue: boolean = true
const isNotTrue = !isTrue

// Array
const listOfNumbers: number[] = [1, 2 ,3]
const otherList: Array<number> = [72, 14] // Sería un array pero es preferible la anotación anterior

// Object
const person: { name: string, age: number} = {
  name: 'Alberto',
  age: 33
}

const personWrong: { name: string, age: number} = {
  name: true, // TS2322: Type 'number' is not assignable to type 'string'.
  age: 33
}

Esto es solo el principio.

En próximos artículos veremos diferentes tipos más complejos y una gran cantidad de herramientas que nos aporta TypeScript para definir nuestros datos.

Artículo original: https://albertochamorro.dev/blog/typescript-capitulo-1-que-es-como-instalar-y-tipos-basicos

¡Gracias por leer hasta aquí y hasta la próxima 👋!

Cómo tener diferentes versiones de Node.js

Alberto Chamorro — Fri, 03 Jun 2022 07:46:47 +0000

Cuantas veces te ha ocurrido que trabajas en diferentes proyectos con JavaScript pero utilizan versiones diferentes de Node.js.

¿Sabías que existen gestores de versiones que te facilitan el cambio entre versiones? Aquí te enseño dos de los más famosos: NVM y N

NVM

NVM (https://nvm.sh/) (o Node Version Manager) es sin lugar a dudas el gestor de versiones de Node.js más conocido y extendido, con más de 58K estrellas en GitHub.

Este gestor de versiones se instala como un comando en tu terminal y es compatible con terminales UNIX, macOS y Windows WSL. Te permite tener descargadas diferentes versiones de Node.js y cambiar de manera global entre ellas.

NVM funciona en cualquier terminal POSIX (sh, dash, ksh, zsh, bash)

Instalación y configuración

Para instalar o actualizar simplemente necesitas ejecutar un script con una de estas dos opciones:



$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash



$ wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

Este script clonará el repositorio de nvm en $NVM_DIR/.nvm (por defecto NVM_DIR será tu directorio HOME) e intentará añadir la configuración necesaria a tu fichero de preferencias. Una vez recargues tu terminal ya tendrás el comando nvm listo para funcionar.



$ nvm -v
0.39.1

También si estás utilizando el sistema operativo macOS puedes instalar NVM gracias a Homebrew (https://brew.sh/):



$ brew install nvm

Comandos útiles

nvm ls-remote: lista todas las versiones disponibles de Node.js para descargar y utilizar (no te asustes que ya te digo que son muchas 😋).
nvm ls: lista las versiones que tienes descargadas en tu ordenador.
nvm install <VERSION>: descarga la versión que le pasemos por parámetro. Podemos indicar la versión en formato numérico (14.7.0), "stable" para instalar la última versión estable o "lts/" seguido del nombre de la versión que queramos, por ejemplo, "lts/gallium".
nvm use <VERSION>: configura de manera global la versión que le indiquemos para empezar a utilizarla.
nvm uninstall <VERSION>: elimina de tu ordenador la versión que le digamos.
nvm current: muestra la versión de Node.js activa (igual que hacer node -v).
nvm exec <VERSION> <COMANDO>: ejecuta el comando en la versión que le digamos.
nvm run <VERSION> <ARGS>: ejecuta el comando node con la versión y argumentos que le indiquemos.
nvm reinstall-packages <VERSION>: reinstala los paquetes globales con la versión que le digamos.



$ nvm current
v16.15.1

$ nvm install stable
Downloading and installing node v18.3.0...
Local cache found: ${NVM_DIR}/.cache/bin/node-v18.3.0-darwin-arm64/node-v18.3.0-darwin-arm64.tar.xz
Computing checksum with shasum -a 256
Checksums do not match: '413d8691e8dee241cfca660b17c3857f4bb63a35e87cddef893da52b83a91e51' found, '437e836a1e77d3e19c6e8a7526b8077fb38062a01511b99f3801457db6a63bec' expected.
Checksum check failed!
Removing the broken local cache...
Downloading https://nodejs.org/dist/v18.3.0/node-v18.3.0-darwin-arm64.tar.xz...
################################################################################################################################### 100.0%
Computing checksum with shasum -a 256
Checksums matched!
Now using node v18.3.0 (npm v7.24.2)

$ nvm current
v18.3.0

$ nvm use 16
Now using node v16.15.1 (npm v7.24.2)

Fichero .nvmrc

Puede que al empezar a trabajar en un proyecto veas un fichero .nvmrc en el directorio raíz. Este fichero indica la versión de Node.js que se está utilizando en ese proyecto y que tú deberías también utilizar.

NVM buscará y utilizará la versión indicada en ese fichero para ejecutar los comandos si nosotros no especificamos una versión:



$ nvm current
v18.3.0

$ cat .nvmrc
v16.15.1

$ nvm use
Found '/Users/alberto/workspace/personal/albertochamorro.dev/.nvmrc' with version <v16.15.1>
Now using node v16.15.1 (npm v7.24.2)

En la documentación de NVM, sección "Deeper Shell Integration" (https://github.com/nvm-sh/nvm#deeper-shell-integration), te enseñan a automatizar tu terminal para ejecutar el comando nvm use cada vez que accedes a un directorio que contiene un fichero .nvmrc.

N

N (https://github.com/tj/n) es otro conocido gestor de versiones de Node.js pero con una filosofía diferente a NVM. Sus creadores indican que lo han hecho mucho más sencillo que NVM sin tener que modificar la configuración del usuario para funcionar.

Este gestor de versiones también se instala como un comando en tu terminal y es compatible con sistemas UNIX, macOS y Windows WSL.

Instalación y configuración

Hay varias formas con las que puedes instalar N.

Si por ejemplo ya tuvieras Node.js y npm instalados bastaría con ejecutar:



$ npm install -g n

Si, por el contrario, aún no tienes npm estos serían los comandos a ejecutar:



$ curl -L https://raw.githubusercontent.com/tj/n/master/bin/n -o n
$ bash n lts
$ npm install -g n

O si estás en Linux o macOS tienes un instalador en un sólo paso:



curl -L https://bit.ly/n-install | bash

La instalación por defecto se hará en /usr/local/n pero podríamos modificar el directorio donde queremos tener N estableciendo la variable de entorno N_PREFIX antes de la instalación.

Una vez terminemos la instalación podemos confirmar que tenemos N ejecutando:



$ n --version

v8.2.0

Comandos útiles

n: si no tenemos ninguna versión de Node.js descargada mostrará la ayuda. En caso de tener alguna versión descargada nos mostrará un selector interactivo para poder cambiar a la versión que queramos.
n ls-remote: lista las últimas versiones disponibles de Node.js. Si queremos ver todas añadiremos --all al comando.
n ls: lista las versiones que tienes descargadas en tu ordenador.
n install <VERSION>: descarga la versión que le pasemos por parámetro.
n use <VERSION>: configura de manera global la versión que le indiquemos para empezar a utilizarla.
n rm <VERSION>: elimina de tu ordenador la versión que le digamos.
n exec <VERSION> <COMANDO>: ejecuta el comando en la versión que le digamos.
n run <VERSION> <ARGS>: ejecuta el comando node con la versión y argumentos que le indiquemos.
n prune: elimina todas las versiones descargadas menos la que está en uso en ese momento.
n uninstall: eliminar la versión que está en uso en ese momento

Algunos comandos tienen alias definidos para facilitar su uso:

install: i
latest: current
ls: list
lsr: ls-remote
lts: stable
rm: -
run: use, as
which: bin

Definir versiones de Node.js

Al igual que con NVM decíamos que se utilizaba el fichero .nvmrc para definir la versión de Node.js del proyecto, con N tenemos soporte a diferentes mecanismos.

N lee la versión en el directorio actual o cualquier directorio principal, buscando en el siguiente orden:

.n-node-version: fichero propio de n.
.node-version: fichero común a otras herramientas (https://github.com/shadowspawn/node-version-usage).
.nvmrc: usado por NVM
Si no existe ninguno de los ficheros anteriores, busca la propiedad engines (https://docs.npmjs.com/cli/v7/configuring-npm/package-json#engines) dentro del fichero package.json y utiliza npx semver para resolver rangos complejos.

¿Conocías estas herramientas? ¿Vas a empezar a utilizarlas si no lo hacías ya? Espero que después de leer el artículo te anime al menos a probarlas 😊.

Artículo original: https://albertochamorro.dev/blog/diferentes-versiones-de-nodejs

¡Gracias por leer hasta aquí y hasta la próxima 👋!

Conventional Commits - Qué es y por qué deberías empezar a utilizarlo

Alberto Chamorro — Wed, 19 Jan 2022 10:17:58 +0000

¿Alguna vez te ha pasado que no sabes que formato usar al escribir un mensaje de un commit? ¿Cada persona del equipo sigue un formato diferente porque no hay un acuerdo entre todos? O lo que es peor, ¿usa emojis en los commits? Yo he sido de esos...

Pues Conventional Commits llega para solucionar todos esos problemas y más.

Pero, ¿qué es Conventional Commits?

Conventional Commits es una convención en el formato de los mensajes de los commits. Esta convención define una serie de reglas que hacen muy sencillo tanto la legibilidad del histórico del repositorio como el poder tener herramientas que automaticen procesos basándose en el historial de commits, por ejemplo, a la hora del versionado del proyecto.

Esta convención está muy ligada con Semantic Versioning (o SemVer), estableciendo la versión del proyecto basándose en los commits del repositorio.

Conventional Commits es una especificación para dar significado a los mensajes de los commits haciéndolos legibles para máquinas y humanos.

Pero, ¿qué es Semantic Versioning o SemVer?

A modo resumen, SemVer es la convención más extendida para establecer un versionado a librerías, paquetes, dependencias, y a la vida en general 🙃

El versionado se divide en tres bloques:

// MAJOR.MINOR.PATCH

2.12.7
// 2 -> MAJOR
// 12 -> MINOR
// 7 -> PATCH

MAJOR: número de versión que se incrementa cuando se rompe la compatibilidad de versiones anteriores.
MINOR: número de versión que se incrementa cuando se añade funcionalidad y esta es compatible en la versión MAJOR actual.
PATCH: número de versión que se incrementa cuando se arreglan errores en la versión MAJOR.MINOR actual.

Adicionalmente está permitido (y es muy común) añadir al bloque PATCH información adicional indicando si son versiones previas a un nuevo lanzamiento (alpha, beta, next, rc, ...) y el número de la compilación. Esta información adicional debe ir en el bloque PATCH precedido por un guión -.

Un ejemplo:

12.2.0-alpha.0

// Aquí "alpha" indica el estado de la compilación y ".0" indica el número de compilación

Todo el detalle puedes consultarlo en la página oficial de SemVer. Ahora sí, volvamos a Conventional Commits.

Especificación de Conventional Commits

Conventional Commits especifica que el mensaje de commit debe ser estructurado de la siguiente manera:

<tipo>(ámbito opcional): <descripción>
<LINEA_EN_BLANCO>
[cuerpo opcional]
<LINEA_EN_BLANCO>
[nota(s) al pie opcional(es)]

Hay ciertos elementos que serán utilizados para comunicar la intención del commit a terceros:

Si el tipo es fix indica que el commit es un parche de un error y está relacionado con la versión PATCH del proyecto.
Si el tipo es feat indica que el commit añade una nueva funcionalidad y se relaciona con la versión MINOR del proyecto.
Añadir el texto BREAKING CHANGE en el footer de un commit, o el carácter ! después del tipo, indica que se rompe la compatibilidad de la versión actual y está relacionado con la versión MAJOR del proyecto.

Espero que aún no hayas hecho 🤯 porque de verdad que es muy sencillo. Vamos a ver cada una de las zonas del commit en detalle.

Tipo

El primer elemento es el tipo de commit refiriéndose al contenido del commit. Basados en la convención establecida por Angular estos son:

feat: cuando se añade una nueva funcionalidad.
fix: cuando se arregla un error.
chore: tareas rutinarias que no sean específicas de una feature o un error como por ejemplo añadir contenido al fichero .gitignore o instalar una dependencia.
test: si añadimos o arreglamos tests.
docs: cuando solo se modifica documentación.
build: cuando el cambio afecta al compilado del proyecto.
ci: el cambio afecta a ficheros de configuración y scripts relacionados con la integración continua.
style: cambios de legibilidad o formateo de código que no afecta a funcionalidad.
refactor: cambio de código que no corrige errores ni añade funcionalidad, pero mejora el código.
perf: usado para mejoras de rendimiento.
revert: si el commit revierte un commit anterior. Debería indicarse el hash del commit que se revierte.

Ámbito

El campo ámbito es opcional y sirve para dar información contextual como por ejemplo indicar el nombre de la feature a la que afecta el commit.

Descripción

Breve descripción del cambio cumpliendo lo siguiente:

usa imperativos, en tiempo presente: “añade” mejor que “añadido” o “añadidos”
la primera letra siempre irá en minúscula
no escribir un punto al final

Cuerpo

Es opcional y debería añadir aportar más información que la descripción. Debería usar el mismo tono imperativo que esta.

Nota al pie

Es opcional. Siempre se utiliza para indicar cambios que rompan la compatibilidad de la versión actual (Breaking Changes) aunque también están permitidos otros formatos que sigan la convención de git trailer format.

Si el pie de página indica un Breaking Change, el formato deberá ser el siguiente:

BREAKING CHANGE: <description>

¿A que no ha sido tan difícil? Venga que seguro que unos ejemplos te ayudan.

Ejemplos

Commit rompiendo la compatibilidad de la versión actual

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Mismo commit que antes pero indicando la ruptura de compatibilidad con `!`

feat!: allow provided config object to extend other configs

Commit con ámbito

feat(lang): add spanish language

Commit con cuerpo y notas al pie

fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

¿Por qué usar Conventional Commits?

Conseguimos un acuerdo en el formato de los commits con todo el equipo de desarrollo tanto interno como externo
Armonía en el histórico del repositorio
Generación automática de CHANGELOG
Versionado automático del proyecto

Herramientas

Hay muchas librerías, extensiones y linters que se integran con la convención de Conventional Commits para validar los mensajes de los commits, generar documentación como alimentar el fichero CHANGELOG o para versionar automáticamente el proyecto.

En la web de Conventional Commits se listan un montón de estas herramientas para Go, Python, PHP, Java y JavaScript. Además hay plugins para tu editor favorito seguro así que te animo a que pases a echarle un vistazo.

Algunas de las más famosas en el ecosistema JavaScript son:

standard-version: librería creada por la gente de Conventional commits, automatiza la generación del CHANGELOG y genera la siguiente versión en base a las tags de versiones anteriores en tu repositorio y a los commits posteriores a esa tag. Genera un commit incluyendo la versión en el mensaje y los ficheros que ha creado/actualizado automáticamente y el tag con la nueva versión.
semantic-release: otra herramienta más completa que la anterior y más extendida por la comunidad. Automatiza todo el flujo de desarrollo y versionado trabajando con ramas (master, next, beta, alpha, etc), genera versionado analizando las tags en estas ramas y los commits, genera las notas de la nueva versión, realiza commit con todos los cambios y lanza la publicación del paquete. ¡Un todo en uno en toda regla!
multi-semantic-release: si lo tuyo son los monorepos esta es tu librería. Sigue el mismo concepto que semantic-release pero funciona con monorepos, determinando el versionado para cada uno de los workspaces dentro de tu proyecto.
commitlint: uno de los linters más famosos cuando hablamos de mensajes de commits y con una integración directa con Conventional Commits. Puedes usarlo por ejemplo con simple-git-hooks o husky para validar los mensajes del proyecto antes de que se registren en el histórico del repositorio y poder rechazarlo si no cumple el formato.

Algunos proyectos que lo usan

Espero que a partir de ahora utilices esta convención para tus commits, estaré vigilándote 🕵️‍.

Artículo original: https://albertochamorro.dev/blog/conventional-commits-que-es

¡Gracias por leer hasta aquí y hasta la próxima 👋!

DEV Community: Alberto Chamorro

TypeScript [Capítulo 1] ¿Qué es TypeScript? Instalación y tipos básicos

¿Qué es TypeScript?

TypeScript vs JavaScript

¡Quiero empezar! ¿Cómo lo instalo?

Tipado o type annotations

Inferencia de tipos

Tipos básicos

Cómo tener diferentes versiones de Node.js

NVM

Instalación y configuración

Comandos útiles

Fichero .nvmrc

N

Instalación y configuración

Comandos útiles

Definir versiones de Node.js

Conventional Commits - Qué es y por qué deberías empezar a utilizarlo

Pero, ¿qué es Conventional Commits?

Pero, ¿qué es Semantic Versioning o SemVer?

Especificación de Conventional Commits

Tipo

Ámbito

Descripción

Cuerpo

Nota al pie

Ejemplos

Commit rompiendo la compatibilidad de la versión actual

Mismo commit que antes pero indicando la ruptura de compatibilidad con !

Commit con ámbito

Commit con cuerpo y notas al pie

¿Por qué usar Conventional Commits?

Herramientas

Algunos proyectos que lo usan

Mismo commit que antes pero indicando la ruptura de compatibilidad con `!`