Typescript · DacaCode

TypeScript: Depuración de errores y tsconfig.json

Dacadev — Wed, 24 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Artículo final de la serie sobre TypeScript. Consolidaremos la configuración del compilador mediante tsconfig.json y las opciones que facilitan la depuración y mejoran la calidad del código emitido.

El archivo tsconfig.json es el centro de control del compilador: define cómo TypeScript interpreta, verifica y transforma tu proyecto. Una configuración bien afinada no solo previene errores, sino que mejora la experiencia de depuración y la calidad del JavaScript resultante. Cerremos la serie dominando esta pieza. La referencia completa está en la documentación oficial de tsconfig.json.

Qué es tsconfig.json y para qué sirve

tsconfig.json declara el comportamiento del compilador para todo el proyecto. Cuando se genera por primera vez, muchas opciones aparecen comentadas, y el valor mostrado en el comentario suele ser el recomendado por defecto.

Info

La presencia de un tsconfig.json en un directorio marca la raíz de un proyecto TypeScript. Ejecutar tsc sin argumentos hace que el compilador busque este archivo y compile según sus reglas.

Opciones recomendadas

Estas opciones de compilerOptions aportan el mayor valor en un proyecto profesional:

strict: activa el conjunto completo de comprobaciones estrictas. Es la opción que más errores previene.
noImplicitAny: prohíbe que TypeScript asigne any de forma implícita cuando no puede inferir un tipo, obligándote a ser explícito.
removeComments: elimina los comentarios del JavaScript compilado, produciendo una salida más limpia.
sourceMap: genera source maps que enlazan el JavaScript emitido con tu código TypeScript original.

{
 "compilerOptions": {
 "strict": true,
 "noImplicitAny": true,
 "removeComments": true,
 "sourceMap": true,
 "target": "es2015",
 "module": "commonjs",
 "outDir": "dist"
 },
 "include": ["src"]
}

Tip

strict es en realidad un paraguas que activa varias comprobaciones, entre ellas noImplicitAny, strictNullChecks y strictFunctionTypes. Habilitarlo desde el primer commit evita una migración costosa cuando el proyecto ya acumuló tipos implícitos.

sourceMap: depurar el código original

Sin source maps, cuando depuras en el navegador o en Node solo ves el JavaScript transpilado, que puede diferir notablemente de tu TypeScript. Con sourceMap: true, el compilador genera archivos .js.map que permiten al depurador mostrar tu código fuente original, colocar breakpoints en él e inspeccionar variables con sus nombres reales.

Esta opción es la diferencia entre depurar el código que escribiste y depurar el código que la máquina generó.

Generar un único archivo de salida

Para ciertos escenarios —especialmente proyectos de frontend sin un bundler— resulta útil concatenar toda la salida en un solo archivo JavaScript. Esto se logra con la opción outFile:

{
 "compilerOptions": {
 "outFile": "./main.js",
 "sourceMap": true,
 "removeComments": true
 }
}

Warning

outFile solo funciona con los sistemas de módulos amd y system; no es compatible con commonjs ni esnext. En proyectos modernos, lo habitual es delegar el empaquetado a herramientas como webpack o esbuild en lugar de usar outFile.

Depurar errores con eficacia

El flujo de depuración en TypeScript combina las opciones anteriores con la lectura disciplinada de los mensajes del compilador:

Cada error incluye un código (por ejemplo TS2345) que puedes buscar para entender su causa raíz.
Con strict activo, los errores afloran en compilación, antes de ejecutar el código.
Con sourceMap, los errores en tiempo de ejecución apuntan a tu TypeScript original, no al JavaScript emitido.
El modo observador (tsc --watch) reporta los errores de forma incremental mientras escribes.

flowchart LR
 A[Código TS] --> B[tsc con strict]
 B -- error de tipo --> C[Mensaje TSxxxx
en compilación]
 B -- ok --> D[JS + sourceMap]
 D --> E[Runtime]
 E -- error --> F[Stack trace sobre TS
gracias al sourceMap]

Conclusión

tsconfig.json es la herramienta que transforma TypeScript de un transpilador genérico en un compilador afinado a tu proyecto. Activar strict y noImplicitAny maximiza la detección temprana de errores; sourceMap hace que la depuración opere sobre tu código real; y removeComments pule la salida. Dominar estas opciones cierra el ciclo: del tipado en el editor a la depuración en producción.

Con esto concluye la serie sobre TypeScript. Has recorrido desde la instalación y los tipos básicos hasta los genéricos, los decoradores y la configuración del compilador: el conjunto de herramientas necesario para construir aplicaciones robustas y mantenibles con tipado estático.

TypeScript: Namespaces, módulos e importaciones

Dacadev — Tue, 23 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Décimo artículo de la serie sobre TypeScript. Organizaremos el código con namespaces y módulos ES: exportaciones nombradas, import, alias, export default y archivos barrel.

A medida que un proyecto crece, la organización del código deja de ser un detalle estético para convertirse en un factor de mantenibilidad. TypeScript ofrece dos mecanismos para estructurar el código: los namespaces —agrupadores internos— y los módulos ES —el estándar moderno basado en export e import. Analicemos cuándo usar cada uno.

Namespaces

Un namespace agrupa funciones, clases y variables relacionadas bajo un identificador común, exponiendo solo lo que marques con export:

namespace Validations {
 export const validateText = (text: string): boolean => {
 return text.length > 3
 }

 export const validateDate = (myDate: Date): boolean => {
 return !isNaN(myDate.valueOf())
 }
}

Validations.validateText('hola mundo')

Solo los miembros exportados (validateText, validateDate) son accesibles desde fuera mediante la notación Namespace.miembro.

Info

Los namespaces se usan cada vez menos en el desarrollo de aplicaciones, donde los módulos ES son el estándar. Sin embargo, siguen presentes como base interna de muchos frameworks y de archivos de definición de tipos (.d.ts).

Módulos: export e import

Los módulos son el mecanismo recomendado. Cada archivo es un módulo y expone su API con export; otros archivos la consumen con import. Para exportar, antepón export a la declaración:

// classes/Heros.ts
export class Hero {
 constructor(
 public name: string,
 public powerID: number,
 public age: number
 ) {}
}

Y para consumirla, usa import con desestructuración de los miembros nombrados:

// index.ts
import { Hero } from './classes/Heros'

const spiderman: Hero = new Hero('Spiderman', 100, 23)

Archivos barrel: centralizar exportaciones

Cuando una carpeta agrupa varios módulos relacionados, importarlos uno a uno desde rutas distintas se vuelve tedioso. Un archivo barrel —convencionalmente un index.ts dentro de la carpeta— reexporta todo desde un único punto de entrada:

// interfaces/index.ts
export { Hero } from './hero'
export { Villain } from './villain'

Esto permite importar múltiples miembros refiriéndote solo a la carpeta, lo que simplifica las rutas y desacopla a los consumidores de la estructura interna:

import { Hero, Villain } from './interfaces'

flowchart LR
 H[hero.ts] --> I[index.ts barrel]
 V[villain.ts] --> I
 I --> C[consumidor: import desde './interfaces']

Export alias

Un alias renombra un miembro al importarlo, lo que resuelve colisiones de nombres entre módulos distintos. Se usa la palabra clave as:

import { powers as poderes } from './data/powers'

console.log(poderes)

Export default

Una exportación por defecto designa el valor principal de un módulo. Se importa sin llaves y puede combinarse con importaciones nombradas en la misma línea:

// data/powers.ts
export default class Powers {
 /* ... */
}
export const powers = ['fuerza', 'velocidad']

import Powers, { powers as poderes } from './data/powers'

Powers corresponde a la exportación por defecto y poderes a una exportación nombrada renombrada con alias.

Tip

Prefiere las exportaciones nombradas frente a export default en bases de código grandes: facilitan el autocompletado, el refactoring automático y mantienen nombres consistentes entre el módulo y sus consumidores.

Del código a un bundle

Los módulos resuelven la organización en tiempo de desarrollo, pero el navegador necesita servir el resultado de forma eficiente. Empaquetadores como webpack combinan todos los módulos en uno o pocos archivos optimizados, resolviendo el grafo de dependencias que tejen tus import. TypeScript se integra en este flujo transpilando primero a JavaScript y dejando que el bundler se encargue del empaquetado final.

Conclusión

Estructurar el código es una decisión de arquitectura. Los namespaces agrupan elementos internos y persisten en definiciones de tipos, pero el estándar moderno son los módulos ES con export/import. Los archivos barrel centralizan las exportaciones, los alias resuelven colisiones de nombres y export default designa el valor principal de un módulo.

En el artículo final de la serie consolidaremos la configuración del compilador y la depuración de errores mediante tsconfig.json.

TypeScript: Decoradores y metaprogramación

Dacadev — Mon, 22 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Noveno artículo de la serie sobre TypeScript. Estudiaremos los decoradores: funciones que se ejecutan en la definición de clases, métodos y propiedades para extender su comportamiento sin modificar su código original.

Un decorador en TypeScript es una función que se ejecuta en tiempo de transpilación y permite expandir la funcionalidad de un objeto —clase, método o propiedad— de forma declarativa. Frameworks como Angular o NestJS apoyan gran parte de su ergonomía en este mecanismo. Analicemos cada variante con ejemplos prácticos. Puedes consultar la referencia completa en la documentación oficial de decoradores.

Info

Los decoradores se colocan con la sintaxis @nombre justo antes del elemento a decorar. Por convención se declaran con function —en lugar de arrow functions— para distinguirlos visualmente de las funciones ordinarias.

Decoradores de clase

Un decorador de clase recibe el constructor y se ejecuta una sola vez, en el momento en que se define la clase —no al crear cada instancia:

function printToConsole(constructor: Function) {
 console.log(constructor)
}

@printToConsole
export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'

 constructor(public name: string) {}
}

Al crear varias instancias, el decorador no vuelve a ejecutarse: su efecto ocurre en la definición, no en la instanciación.

Decoradores de fábrica

Un decorador de fábrica es una función que retorna el decorador real. Esto permite parametrizar el comportamiento, aceptando argumentos que controlan cómo se aplica:

function printToConsole(constructor: Function) {
 console.log(constructor)
}

const printToConsoleConditional = (print: boolean = true): Function => {
 return print ? printToConsole : () => {}
}

@printToConsoleConditional(false)
export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'
 constructor(public name: string) {}
}

Un patrón habitual es sellar el prototipo para impedir que se alteren sus propiedades en tiempo de ejecución:

const blockPrototype = function (constructor: Function) {
 Object.seal(constructor)
 Object.seal(constructor.prototype)
}

@blockPrototype
@printToConsoleConditional(false)
export class Pokemon {
 // ...
}

Tip

Cuando aplicas múltiples decoradores, se ejecutan de forma secuencial de abajo hacia arriba. En el ejemplo anterior, primero corre printToConsoleConditional y luego blockPrototype.

Decoradores de método

Un decorador de método recibe tres argumentos —el objeto al que pertenece, el nombre del método y su PropertyDescriptor— y puede inspeccionar o reemplazar por completo el comportamiento del método. Aquí lo usamos para validar argumentos:

function CheckValidPokemonId() {
 return function (
 target: any,
 propertyKey: string,
 descriptor: PropertyDescriptor
 ) {
 const originalMethod = descriptor.value

 descriptor.value = (id: number) => {
 if (id < 1 || id > 100) {
 return console.error('El id del pokemon debe estar entre 1 y 100')
 }
 return originalMethod(id)
 }
 }
}

export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'
 constructor(public name: string) {}

 @CheckValidPokemonId()
 savePokemonToDB(id: number) {
 console.log(`Pokemon guardado en la base de datos ${id}`)
 }
}

Al envolver originalMethod, el decorador intercepta la llamada, valida el id y solo delega al método original cuando el valor es válido. Este es el fundamento de las validaciones declarativas de muchos frameworks.

Decoradores de propiedad

Un decorador de propiedad recibe el objeto y el nombre de la propiedad, y puede alterar cómo se lee y escribe. Es útil para controlar el acceso a datos —recordando que JavaScript no tiene propiedades verdaderamente privadas en runtime:

function readOnly(isWriteable: boolean = true): Function {
 return function (target: any, propertyKey: string) {
 const descriptor: PropertyDescriptor = {
 get() {
 return 'Daca code'
 },
 set(this, val) {
 Object.defineProperty(this, propertyKey, {
 value: val,
 writable: !isWriteable,
 enumerable: false
 })
 }
 }
 return descriptor
 }
}

export class Pokemon {
 @readOnly(false)
 private publicApi: string = 'https://pokeapi.co'

 constructor(public name: string) {}
}

El decorador define un get/set personalizado que gobierna por completo el acceso a publicApi.

Conclusión

Los decoradores aportan metaprogramación declarativa a TypeScript: el decorador de clase actúa sobre el constructor una única vez, el de fábrica parametriza el comportamiento, el de método intercepta y reemplaza llamadas, y el de propiedad controla la lectura y escritura. Componerlos en cadena —respetando su orden de ejecución— es lo que habilita las APIs elegantes de frameworks modernos.

En el próximo artículo organizaremos el código con namespaces y módulos: export, import, alias y exportaciones por defecto.

TypeScript: Tipos avanzados, subtipos y varianza

Dacadev — Sun, 21 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Octavo artículo de la serie sobre TypeScript. Abordaremos la teoría que sustenta el sistema de tipos: subtipos, supertipos, la jerarquía completa, los tipos unknown y never, y la varianza.

Comprender la relación entre tipos es lo que separa a quien usa TypeScript de quien lo domina. El compilador decide qué asignaciones son válidas aplicando reglas de subtipado y varianza. Una vez interiorizadas estas reglas, los errores del typechecker dejan de ser obstáculos crípticos y se convierten en información precisa sobre el diseño de tus tipos.

Subtipos

La regla fundamental del subtipado se enuncia así:

Info

Si tienes un tipo A y un tipo B donde B es subtipo de A, entonces puedes usar B en cualquier lugar donde se espere un A.

Algunas relaciones de subtipo en TypeScript:

Array es subtipo de Object.
Tuple es subtipo de Array.
Todo es subtipo de any.
never es subtipo de todo.
Si una clase Bird extiende Animal, entonces Bird es subtipo de Animal.

Aplicado a la práctica, esto significa que donde se necesite un Object puedes usar un Array; donde se necesite un Array puedes usar una Tuple; y donde se necesite un Animal puedes usar un Bird.

Supertipos

Un supertipo es la relación inversa:

Info

Si tienes un tipo A y un tipo B donde B es supertipo de A, entonces puedes usar A en cualquier lugar donde se espere un B.

Las relaciones de supertipo reflejan en espejo a las anteriores:

Array es supertipo de Tuple.
Object es supertipo de Array.
any es supertipo de todo.
Animal es supertipo de Bird.

La jerarquía de tipos

Todas estas relaciones forman una jerarquía con un tipo en la cúspide (top type) y otro en el fondo (bottom type):

flowchart TD
 Unknown[unknown - top type] --> Any[any]
 Any --> Number
 Any --> BigInt
 Any --> Boolean
 Any --> String
 Any --> Symbol
 Any --> Object
 Any --> Void
 Any --> Null
 Any --> Undefined
 Object --> Array
 Array --> Tuple
 Object --> Function
 Number --> Never[never - bottom type]
 String --> Never
 Boolean --> Never
 Object --> Never
 Tuple --> Never

unknown es el top type: todo es asignable a él, pero no permite operar sin acotar primero.
never es el bottom type: es subtipo de cualquier otro tipo y representa lo que nunca ocurre.

Los tipos especiales: null, undefined, void y never

Estos cuatro tipos modelan la ausencia de valor con matices distintos:

Tipo	Significado
`null`	Ausencia explícita de valor
`undefined`	Variable que aún no recibió un valor
`void`	Función que no tiene sentencia `return`
`never`	Función que nunca retorna

La distinción entre void y never es sutil pero importante. Una función void termina sin devolver nada útil; una función never no termina en absoluto, ya sea porque lanza una excepción o porque entra en un bucle infinito:

// void: termina, no retorna valor
function log(msg: string): void {
 console.log(msg)
}

// never: nunca completa su ejecución
function fail(message: string): never {
 throw new Error(message)
}

function loopForever(): never {
 while (true) {}
}

Tip

never es especialmente útil en la verificación de exhaustividad: si un switch cubre todos los casos de una unión, la rama default puede asignar el valor a un never, y el compilador detectará en tiempo de compilación cualquier caso olvidado al ampliar la unión.

Varianza

Determinar si un tipo es sub o supertipo de otro no siempre es evidente, sobre todo al combinar estructuras y funciones. TypeScript dispone de una notación formal para razonar sobre estas relaciones:

A <: B significa “A es subtipo de, o el mismo tipo que, B”.
A >: B significa “A es supertipo de, o el mismo tipo que, B”.

La varianza describe cómo se propagan estas relaciones cuando los tipos se anidan en estructuras (arreglos, objetos) o en firmas de función. Es el motivo por el que, por ejemplo, un arreglo de un subtipo no siempre es intercambiable con un arreglo de su supertipo: la mutabilidad introduce restricciones que el compilador debe respetar para mantener la solidez del sistema.

Conclusión

El sistema de tipos de TypeScript es una jerarquía gobernada por reglas de subtipado y varianza, con unknown como tipo superior y never como tipo inferior. Distinguir null, undefined, void y never, y comprender cómo B <: A permite sustituir un tipo por otro, te da una intuición precisa de por qué el compilador acepta o rechaza una asignación.

En el siguiente artículo aplicaremos metaprogramación con decoradores, funciones que extienden el comportamiento de clases, métodos y propiedades.

TypeScript: Genéricos y código reutilizable

Dacadev — Sat, 20 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Séptimo artículo de la serie sobre TypeScript. Exploraremos los genéricos: funciones y clases que operan sobre tipos dinámicos sin renunciar a la verificación estática.

Los genéricos en TypeScript resuelven una tensión recurrente: escribir código reutilizable que funcione con cualquier tipo, pero sin caer en any y perder toda la seguridad. Un genérico introduce un parámetro de tipo —una variable que representa un tipo aún por determinar— que se resuelve en el momento de uso. Analicemos cómo aplicarlos.

Funciones genéricas

Una función genérica declara su parámetro de tipo con la sintaxis <T> antes de la lista de parámetros. T representa el tipo que recibirá, y la función puede usarlo para tipar argumentos y retorno:

// Función tradicional
export function genericFunction<T>(argumento: T): T {
 return argumento
}

// Arrow function
export const genericArrowFunction = <T>(argumento: T): T => argumento

La función anterior retorna exactamente el mismo tipo que recibe. Si la invocas con un string, TypeScript sabe que el retorno es string; si la invocas con un number, el retorno es number. Esto es lo que distingue a un genérico de any: la relación entre entrada y salida se preserva.

Info

T es el nombre convencional, pero es arbitrario. Para múltiples parámetros suelen usarse T, U, K, V, o nombres descriptivos como TItem cuando aportan claridad.

Por qué no basta con any

Comparemos las dos aproximaciones para entender el valor de los genéricos:

// Con any: se pierde la información de tipo
function identityAny(arg: any): any {
 return arg
}
const a = identityAny('hola') // a es any → sin autocompletado ni verificación

// Con genéricos: el tipo se conserva
function identity<T>(arg: T): T {
 return arg
}
const b = identity('hola') // b es string → seguridad completa

Con any, el resultado pierde todo su tipo y el typechecker deja de ayudar. Con un genérico, la firma encadena el tipo de entrada con el de salida.

Clases genéricas

Las clases también admiten parámetros de tipo, lo que permite construir estructuras de datos reutilizables y type-safe. El parámetro se declara junto al nombre de la clase y queda disponible en todos sus miembros:

class MyMap<K, V> {
 constructor(initialKey: K, initialValue: V) {
 // ...
 }
 get(key: K): V {
 // ...
 }
 set(key: K, value: V): void {
 // ...
 }
 static of<K, V>(k: K, v: V): MyMap<K, V> {
 // ...
 }
}

Al instanciarla, los tipos pueden indicarse explícitamente o inferirse de los argumentos:

let a = new MyMap<string, number>('k', 1) // MyMap<string, number>
let b = new MyMap('k', true) // MyMap<string, boolean> (inferido)

a.get('k')
b.set('k', false)

flowchart LR
 G["MyMap<K, V>"] --> A["MyMap<string, number>"]
 G --> B["MyMap<string, boolean>"]
 G --> C["MyMap<number, Hero>"]

Una sola definición genérica genera tantas variantes type-safe como combinaciones de tipos uses.

Restringir genéricos con extends

A veces un genérico no debe aceptar cualquier tipo, sino solo aquellos que cumplan cierta forma. La cláusula extends impone esa restricción y, a la vez, habilita el acceso seguro a los miembros garantizados:

function getLength<T extends { length: number }>(item: T): number {
 return item.length
}

getLength('hola') // OK: string tiene length
getLength([1, 2, 3]) // OK: array tiene length
getLength(42) // Error: number no tiene 'length'

T extends { length: number } restringe T a tipos que posean una propiedad length, permitiendo usarla con seguridad dentro de la función.

Conclusión

Los genéricos son la herramienta que permite escribir código verdaderamente reutilizable sin sacrificar la verificación de tipos. Las funciones genéricas encadenan el tipo de entrada con el de salida, las clases genéricas habilitan estructuras de datos type-safe, y las restricciones con extends acotan los tipos aceptados mientras exponen sus miembros de forma segura.

En el próximo artículo abordaremos los tipos avanzados: subtipos, supertipos, varianza y la jerarquía completa del sistema de tipos.

TypeScript: Clases, herencia y patrones de diseño

Dacadev — Fri, 19 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Sexto artículo de la serie sobre TypeScript. Recorreremos las clases: herencia, modificadores de acceso, clases abstractas, super, getters/setters, miembros estáticos, tipado estructural y los patrones de diseño que habilitan.

Las clases en TypeScript parten de la sintaxis de JavaScript y la enriquecen con modificadores de acceso, clases abstractas y tipado estructural. El resultado es un modelo de orientación a objetos cercano al de lenguajes como C++ o Java, pero que compila a JavaScript estándar. Analicemos sus capacidades.

Clases y herencia

La declaración usa class y la herencia se establece con extends:

class Piece {}

class King extends Piece {}
class Queen extends Piece {}
class Bishop extends Piece {}

Podemos restringir los atributos a valores concretos combinando clases con tipos literales:

type Color = 'Black' | 'White'
type File = 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H'
type Rank = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

class Position {
 constructor(
 private file: File,
 private rank: Rank
 ) {}
}

Declarar los parámetros del constructor con un modificador (private file: File) es un atajo: TypeScript crea y asigna la propiedad automáticamente, evitando el habitual this.file = file.

Modificadores de acceso

TypeScript define tres niveles de visibilidad para atributos y métodos:

public: accesible desde cualquier lugar. Es el nivel por defecto.
protected: accesible desde la propia clase y sus subclases.
private: accesible únicamente desde la propia clase.

class Avenger {
 constructor(
 private name: string,
 public team: string,
 public realName?: string
 ) {}

 public bio() {
 return `${this.name} ${this.team}`
 }

 private bioInterno() {
 return `${this.realName} ${this.team}`
 }
}

Warning

private y protected solo aplican en tiempo de compilación. El JavaScript emitido no impide el acceso en runtime; para privacidad real en ejecución usa los campos privados nativos de JavaScript (#campo).

Clases abstractas

Una clase abstract define una plantilla que no puede instanciarse, pero sirve de esqueleto para sus subclases. Puede declarar miembros concretos y miembros abstract que las subclases están obligadas a implementar:

abstract class Mutante {
 constructor(
 public name: string,
 public realName: string
 ) {}
}

class Xmen extends Mutante {
 public saveWorld() {
 return 'Mundo salvado'
 }
}

class Villano extends Mutante {
 public conquistWorld() {
 return 'Mundo conquistado'
 }
}

const wolverine = new Xmen('Wolverine', 'Logan')
const magneto = new Villano('Magneto', 'Magnus')

Una ventaja adicional: una función puede aceptar cualquier objeto que herede de la clase abstracta, lo que habilita el polimorfismo:

const printName = (character: Mutante) => {
 console.log(character.name)
}

printName(wolverine)
printName(magneto)

super: invocar a la clase padre

Cuando una subclase sobrescribe un método del padre, puede invocar la versión original con super.metodo(). Si la subclase define un constructor, debe llamar a super() para inicializar correctamente la cadena de herencia:

class Xmen extends Avenger {
 constructor(name: string, realName: string, public isMutant: boolean) {
 super(name, realName)
 }

 public getFullNameDesdeXmen() {
 return super.getFullName()
 }
}

Getters y setters

Los accessors exponen métodos que se comportan sintácticamente como atributos, facilitando la lectura y asignación controladas:

class Xmen extends Avenger {
 get fullName() {
 return `${this.name} - ${this.realName}`
 }

 set fullName(name: string) {
 this.realName = name
 }
}

const wolverine = new Xmen('Wolverine', 'Logan', true)
console.log(wolverine.fullName) // se lee como atributo
wolverine.fullName = 'David' // se asigna como atributo

Miembros estáticos

Los miembros static pertenecen a la clase, no a sus instancias:

class Avenger {
 static avgAge: number = 35
 static getAvgAge() {
 return Avenger.avgAge
 }
}

console.log(Avenger.avgAge) // se accede vía la clase

this como tipo de retorno

Cuando un método retorna la propia instancia, su tipo de retorno es this. Esto es la base del encadenamiento de métodos (method chaining):

class Set {
 add(value: number): this {
 // ...
 return this
 }
}

Tipado estructural

TypeScript verifica las clases por estructura, no por nombre. Dos tipos compatibles en forma son intercambiables, con una salvedad: los miembros private rompen la compatibilidad estructural:

class A {
 private x = 1
}
class B extends A {}

function f(a: A) {}

f(new A()) // OK
f(new B()) // OK
f({ x: 1 }) // Error TS2345: 'x' es private en 'A' pero no en '{x: number}'.

Constructor privado

Un constructor private impide instanciar la clase desde fuera, lo que permite controlar su creación. Es la base del patrón singleton:

class Apocalipsis {
 private static instance: Apocalipsis

 private constructor(public name: string) {}

 static getInstance(): Apocalipsis {
 if (!Apocalipsis.instance) {
 Apocalipsis.instance = new Apocalipsis('Soy Apocalipsis... el único')
 }
 return Apocalipsis.instance
 }
}

const apocalipsis = Apocalipsis.getInstance()

Patrones de diseño habilitados

Factory Pattern

Centraliza la creación de objetos detrás de una función que decide la clase concreta:

type Shoe = { purpose: string }

class BalletFlat implements Shoe { purpose = 'dancing' }
class Boot implements Shoe { purpose = 'woodcutting' }
class Sneaker implements Shoe { purpose = 'walking' }

let Shoe = {
 create(type: 'balletFlat' | 'boot' | 'sneaker'): Shoe {
 switch (type) {
 case 'balletFlat': return new BalletFlat()
 case 'boot': return new Boot()
 case 'sneaker': return new Sneaker()
 }
 }
}

Builder Pattern

Construye un objeto paso a paso mediante métodos que retornan this, habilitando una API fluida:

class RequestBuilder {
 private data: object | null = null
 private method: 'get' | 'post' | null = null
 private url: string | null = null

 setMethod(method: 'get' | 'post'): this {
 this.method = method
 return this
 }
 setData(data: object): this {
 this.data = data
 return this
 }
 setURL(url: string): this {
 this.url = url
 return this
 }

 send() {
 // ...
 }
}

new RequestBuilder().setURL('/api').setMethod('post').setData({}).send()

Conclusión

Las clases de TypeScript ofrecen un modelo de orientación a objetos completo: herencia, modificadores de acceso, clases abstractas para polimorfismo, accessors, miembros estáticos y un tipado estructural con la salvedad de los miembros privados. Estas piezas son el fundamento de patrones de diseño como Factory, Builder y Singleton.

En el siguiente artículo abordaremos los genéricos, la herramienta para escribir código reutilizable sin sacrificar la seguridad de tipos.

TypeScript: Interfaces y contratos de tipos

Dacadev — Thu, 18 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Quinto artículo de la serie sobre TypeScript. Estudiaremos las interfaces como contratos extensibles, su herencia con extends, su implementación en clases con implements, y sus diferencias frente a los alias de tipo.

Una interface en TypeScript define la forma que deben cumplir los objetos. A primera vista se parece a un alias de tipo, pero su rasgo distintivo es la extensibilidad: las interfaces están diseñadas para componerse, heredarse y servir como base de contratos más complejos. Analicemos cuándo y cómo usarlas.

Bases: definir y extender interfaces

Una interface declara la estructura de un objeto. Con extends, una interface puede heredar de otra y ampliar su contrato:

interface Hero {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

interface Avenger extends Hero {
 marvel: string;
}

let flash: Hero = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

Avenger hereda todos los miembros de Hero y añade marvel. Esta composición es la base del diseño orientado a contratos.

Estructuras complejas: interfaces anidadas

Las interfaces pueden referenciarse entre sí para modelar estructuras de datos compuestas:

interface Client {
 name: string;
 age?: number;
 address?: Address;
}

interface Address {
 id: number;
 zip: string;
 city: string;
}

const client: Client = {
 name: 'David',
 address: {
 id: 125,
 zip: 'KYD 234',
 city: 'Chía'
 }
}

const client2: Client = {
 name: 'Melissa',
 age: 30
}

Client referencia a Address como un campo opcional, lo que permite componer entidades de dominio sin acoplarlas en una sola definición monolítica.

Métodos en la interfaz

Al igual que los alias de tipo, las interfaces pueden declarar métodos como parte del contrato:

interface Client {
 name: string;
 age?: number;
 address?: Address;
 getFullAddress(id: string): void;
}

Info

Declarar métodos en una interface es válido, pero implica que el objeto que la cumpla debe implementarlos. En la práctica, cuando un contrato requiere comportamiento, lo más limpio es implementarlo mediante una clase.

Implementar interfaces en clases

Una clase adopta uno o varios contratos con la palabra clave implements. Esto garantiza, en compilación, que la clase provee todo lo que el contrato exige:

interface Xmen {
 name: string;
 realName: string;
 mutantPower(id: number): string;
}

interface Human {
 age: number;
}

class Mutant implements Xmen, Human {
 public age: number;
 public name: string;
 public realName: string;

 mutantPower(id: number): string {
 return 'Hola mundo';
 }
}

Mutant implementa simultáneamente Xmen y Human. Si omitiera cualquier miembro requerido, el compilador lo rechazaría.

Interfaces para tipar funciones

Aunque es poco frecuente, una interface puede describir la firma de una función antes de asignarle una implementación:

interface AddTwoNumbers {
 (a: number, b: number): number;
}

let addNumbers: AddTwoNumbers;

addNumbers = (a: number, b: number): number => a + b

Interfaces frente a alias de tipo

Esta es la decisión de diseño más común. Las tres diferencias clave:

1. Composición

Los alias de tipo componen mediante operaciones de conjuntos (|, &); las interfaces componen mediante extends:

type Food = { calories: number; tasty: boolean }
type Sushi = Food & { salty: boolean }

interface FoodI { calories: number; tasty: boolean }
interface SushiI extends FoodI { salty: boolean }

2. Restricción al extender

Al extender una interface, no puedes cambiar el tipo de un miembro heredado, solo añadir o restringir de forma compatible. Una incompatibilidad genera error:

interface A {
 good(x: number): string
 bad(x: number): string
}

interface B extends A {
 good(x: string | number): string
 bad(x: string): string // Error TS2430: 'B' extiende incorrectamente 'A'.
}

3. Declaration merging

Varias interfaces con el mismo nombre en el mismo ámbito se fusionan automáticamente; varios alias de tipo con el mismo nombre producen un error de compilación:

interface User { name: string }
interface User { age: number } // se fusiona

let a: User = { name: 'Ashley', age: 30 }

type User = { name: string } // Error TS2300: identificador duplicado
type User = { age: number } // Error TS2300

El declaration merging respeta los tipos existentes: no puedes redefinir un miembro ya declarado con otro tipo.

flowchart TD
 Q{¿Necesitas extensibilidad,
implements o merging?}
 Q -- Sí --> I[Usa interface]
 Q -- "No (uniones, tuplas, mapeos)" --> T[Usa type]

Implementación con readonly y múltiples contratos

Las interfaces admiten propiedades readonly y permiten que una clase cumpla varios contratos a la vez:

interface Animal {
 readonly name: string
 eat(food: string): void
 sleep(hours: number): void
}

interface Feline {
 meow(): void
}

class Cat implements Animal, Feline {
 name = 'Whiskers'
 eat(food: string) { console.info('Ate some', food) }
 sleep(hours: number) { console.info('Slept for', hours, 'hours') }
 meow() { console.info('Meow') }
}

Conclusión

Las interfaces son el mecanismo de TypeScript para definir contratos extensibles y verificables. Elige una interface cuando necesites herencia con extends, implementación en clases con implements o declaration merging; reserva los alias de tipo para uniones, intersecciones, tuplas y tipos mapeados.

En el próximo artículo profundizaremos en las clases, la herencia, los modificadores de acceso y los patrones de diseño que habilitan.

TypeScript: Funciones, parámetros y generadores

Dacadev — Wed, 17 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Cuarto artículo de la serie sobre TypeScript. Cubriremos el tipado de funciones: parámetros, tipos de retorno, parámetros opcionales y por defecto, el operador resto, call signatures, generadores e iteradores.

Las funciones son el núcleo de cualquier base de código, y es justo donde el tipado aporta más valor: una firma bien tipada documenta el contrato de entrada y salida, y convierte cualquier llamada inválida en un error de compilación. Analicemos cómo TypeScript modela las funciones en toda su variedad.

Declaración y tipado de funciones

Una función tipada declara el tipo de cada parámetro y, opcionalmente, el tipo de retorno:

function add(a: number, b: number): number {
 return a + b
}

TypeScript admite todas las formas de definir funciones de JavaScript, y a todas les aplica el mismo sistema de tipos:

// Named function
function greet(name: string) {
 return 'hello ' + name
}

// Function expression
let greet2 = function (name: string) {
 return 'hello ' + name
}

// Arrow function
let greet3 = (name: string) => {
 return 'hello ' + name
}

// Shorthand arrow function
let greet4 = (name: string) => 'hello ' + name

El tipado de los parámetros intercepta llamadas inválidas en el sitio exacto del error:

add(1) // Error TS2554: se esperaban 2 argumentos, se recibió 1.
add(1, 'a') // Error TS2345: 'string' no es asignable a 'number'.

Parámetros opcionales y por defecto

Un parámetro opcional se marca con ? y debe gestionarse dentro del cuerpo, ya que puede llegar como undefined:

function log(message: string, userId?: string) {
 let time = new Date().toLocaleTimeString()
 console.log(time, message, userId || 'Not signed in')
}

log('Page loaded')
log('User signed in', 'da763be')

Un parámetro con valor por defecto se vuelve opcional automáticamente, y TypeScript infiere su tipo a partir del valor asignado:

function log(message: string, userId = 'Not signed in') {
 let time = new Date().toISOString()
 console.log(time, message, userId)
}

Warning

Los parámetros opcionales deben ubicarse después de todos los obligatorios, y no pueden combinarse con el operador resto.

También puedes apoyarte en un type para estructurar parámetros de configuración:

type Context = {
 appId?: string
 userId?: string
}

function log(message: string, context: Context = {}) {
 let time = new Date().toISOString()
 console.log(time, message, context.userId)
}

Operador resto: funciones variádicas

El operador resto captura un número dinámico de argumentos en un arreglo tipado, lo que produce firmas más legibles que recibir un arreglo explícito:

// Recibe un arreglo
function sum(numbers: number[]): number {
 return numbers.reduce((total, n) => total + n, 0)
}
sum([1, 2, 3]) // 6

// Variádica con operador resto
function sumVariadicSafe(...numbers: number[]): number {
 return numbers.reduce((total, n) => total + n, 0)
}
sumVariadicSafe(1, 2, 3) // 6

call, apply y bind

TypeScript respeta los mecanismos clásicos de invocación de JavaScript, aplicando la verificación de tipos a sus argumentos:

function add(a: number, b: number): number {
 return a + b
}

add(10, 20) // 30
add.apply(null, [10, 20]) // 30
add.call(null, 10, 20) // 30
add.bind(null, 10, 20)() // 30

Generadores

Los generadores producen valores bajo demanda. Se declaran con un asterisco tras function y emiten valores con yield:

function* createFibonacciGenerator() {
 let a = 0
 let b = 1
 while (true) {
 yield a
 ;[a, b] = [b, a + b]
 }
}

let fib = createFibonacciGenerator() // IterableIterator<number>
fib.next() // { value: 0, done: false }
fib.next() // { value: 1, done: false }
fib.next() // { value: 1, done: false }
fib.next() // { value: 2, done: false }

El método next() extrae el siguiente valor de la secuencia. TypeScript infiere el tipo IterableIterator<number> a partir de lo que produce yield.

Iteradores

Un iterador se define implementando el método [Symbol.iterator]. TypeScript es capaz de reconocer la estructura y tiparla correctamente:

let numbers = {
 *[Symbol.iterator]() {
 for (let n = 1; n <= 10; n++) {
 yield n
 }
 }
}

Call signatures

Una call signature describe el tipo de una función de forma independiente a su implementación. Para la siguiente función:

function sum(a: number, b: number): number {
 return a + b
}

su firma de llamada se expresa así:

(a: number, b: number) => number

El tipo genérico Function es un comodín que no aporta información sobre la firma concreta; las call signatures permiten tipar funciones con precisión. Además, cuando una función puede retornar varios tipos, cada uno debe tratarse para satisfacer al typechecker:

function area(radius: number): number | null {
 if (radius < 0) {
 return null
 }
 return Math.PI * radius ** 2
}

let a = area(3)
if (a !== null) {
 console.info('result:', a) // dentro del guard, a es number
}

Conclusión

El tipado de funciones convierte cada firma en un contrato verificable: parámetros opcionales y por defecto modelan flexibilidad controlada, el operador resto expresa funciones variádicas con claridad, las call signatures tipan funciones como ciudadanos de primera clase, y los generadores e iteradores se integran sin fricción en el sistema de tipos.

En el siguiente artículo abordaremos las interfaces, el mecanismo de TypeScript para definir contratos extensibles.

TypeScript: Objetos y tipos personalizados

Dacadev — Tue, 16 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Tercer artículo de la serie sobre TypeScript. Diseñaremos la forma de nuestros objetos con tipos personalizados, definiremos campos opcionales y métodos, y permitiremos que una variable acepte múltiples tipos.

Modelar correctamente la estructura de los objetos es donde TypeScript empieza a pagar dividendos en proyectos reales. Un tipo personalizado bien diseñado centraliza la definición de una entidad, propaga su forma por todo el código y convierte cualquier desviación en un error de compilación. Analicemos cómo pasar de objetos literales sueltos a un modelo de tipos mantenible.

Objetos literales y la inferencia estructural

Los objetos literales funcionan igual que en JavaScript, pero TypeScript infiere automáticamente su estructura. Esa inferencia es justamente lo que impide reasignar un objeto con una forma distinta:

let flash = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

flash = { name2: 'Otro nombre' }
// Error: el literal solo puede especificar propiedades conocidas;
// 'name2' no existe en el tipo inferido y faltan 'name', 'age', 'powers'.

TypeScript bloquea la reasignación porque el nuevo literal no respeta la forma deducida de flash. Este comportamiento evita introducir campos accidentales o incompletos.

Tipar objetos de forma inline

Podemos declarar explícitamente la forma del objeto usando la misma sintaxis de anotación que venimos aplicando, incluyendo campos opcionales con ?:

let flash: { name: string, age?: number, powers: string[] } = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

flash = {
 name: 'Clark Kent',
 powers: ['volar', 'rayo láser'] // 'age' es opcional, puede omitirse
}

Info

La posición de un campo opcional dentro de la anotación es irrelevante. age? puede ir en medio de la definición sin afectar la validez de los objetos que lo omitan.

El problema de este enfoque inline es la duplicación: si dos variables deben compartir la misma forma, hay que repetir la anotación completa en cada una y mantenerlas sincronizadas manualmente. Esto no escala.

Tipos personalizados con type

La solución es definir la estructura una sola vez con la palabra clave type y reutilizarla en todo el código. Esto centraliza el modelo en un único punto de verdad:

type Hero = {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

let flash: Hero = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

let superman: Hero = {
 name: 'Clark Kent',
 age: 30,
 powers: ['volar', 'rayo láser'],
 getName() {
 return this.name;
 }
}

El tipo Hero declara name y powers como obligatorios, age como opcional y getName como un método opcional cuya firma es () => string. Cualquier objeto anotado con Hero debe respetar este contrato, y un solo cambio en la definición se propaga a todas las variables que lo usan.

flowchart TD
 T[type Hero] --> A[flash: Hero]
 T --> B[superman: Hero]
 T --> C[...otros héroes]
 note["Un cambio en Hero
se propaga a todos"] -.-> T

Tip

Define un type para toda entidad que aparezca más de una vez. La regla práctica: si copiarías la anotación inline por segunda vez, conviértela en un tipo personalizado.

Permitir múltiples tipos con uniones

Una variable puede aceptar más de un tipo mediante el operador de unión |. Esto resulta útil para valores que legítimamente cambian de forma según el contexto:

type Hero = {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

let myCustomVariable: Hero | string | number = '¡Hola mundo!'

myCustomVariable = 42 // válido: number
myCustomVariable = { // válido: Hero
 name: 'Diana',
 powers: ['fuerza sobrehumana']
}

myCustomVariable puede contener un Hero, un string o un number. El typechecker permitirá únicamente operaciones válidas para todos los miembros de la unión hasta que acotes el tipo con un type guard (por ejemplo, typeof o una comprobación de propiedad).

Conclusión

Pasar de objetos literales inline a tipos personalizados con type es el salto que transforma TypeScript de una simple validación a una herramienta de diseño. Un tipo centraliza la forma de una entidad, los campos opcionales modelan la realidad de los datos incompletos, los métodos definen comportamiento esperado y las uniones aportan flexibilidad controlada.

En el próximo artículo de la serie abordaremos las funciones: anotación de parámetros, tipos de retorno, parámetros opcionales y sobrecargas.

TypeScript: Tipos básicos y el sistema de tipos

Dacadev — Mon, 15 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Segundo artículo de la serie sobre TypeScript. Recorreremos el alfabeto de tipos del lenguaje: desde any y unknown hasta uniones, intersecciones, tuplas y alias de tipo.

Cuando el typechecker sabe que un valor es de tipo T, no solo conoce su naturaleza: también sabe exactamente qué operaciones son válidas sobre ese valor y cuáles no. Ese es el propósito del sistema de tipos. Comprender el catálogo de tipos básicos en TypeScript es la base sobre la que se construye todo lo demás, así que dediquémosle la atención que merece.

Por qué importan los tipos: un ejemplo concreto

Los tipos transmiten intención de forma explícita y verificable. Comparemos la misma función en JavaScript y en TypeScript:

// JavaScript
function squareOf(n) {
 return n * n
}
squareOf(2) // 4
squareOf('z') // NaN — falla en silencio

// TypeScript
function squareOf(n: number) {
 return n * n
}
squareOf(2) // 4
squareOf('z') // Error TS2345: el argumento de tipo 'string' no es
 // asignable al parámetro de tipo 'number'.

En JavaScript, squareOf('z') devuelve NaN sin protestar y el error se propaga aguas abajo. En TypeScript el compilador lo intercepta en el sitio exacto donde se cometió.

any: la puerta de escape del sistema de tipos

any indica que una variable puede contener cualquier tipo de dato. Desactiva por completo la verificación:

let avenger: any = 123;
avenger = 'Dr. Strange';
console.log((avenger as string).charAt(0));

avenger = 15.23425;
console.log((<number>avenger).toFixed(2));

Cuando usas any, el typechecker deja de ayudarte. Puedes reorientarlo mediante un cast —indicar manualmente qué tipo debe asumir en un punto dado— con la sintaxis (variable as Tipo) o <Tipo>variable.

Warning

Evita any salvo en migraciones puntuales o fronteras con código sin tipado. Cada any es un agujero por el que se filtran errores que el compilador debería haber detenido.

unknown: la alternativa segura a any

unknown es el primo responsable de any. Acepta cualquier valor, pero TypeScript prohíbe operar sobre él hasta que acotes su tipo mediante una comprobación. Esto añade una capa de seguridad: sí admite operaciones de comparación e identidad (==, ===, ||, &&, el operador ternario ?) y negación con !, pero no el acceso a propiedades arbitrarias.

let dato: unknown = obtenerValor();

// dato.toFixed(2) // Error: 'dato' es de tipo 'unknown'
if (typeof dato === 'number') {
 dato.toFixed(2) // OK: dentro del guard, dato es number
}

Usa unknown siempre que recibas datos externos (respuestas de API, entrada del usuario) en lugar de any.

boolean

Acepta las operaciones ==, ===, ||, &&, el ternario ? y la negación !:

let a = true // boolean
const c = true // true (tipo literal)
let d: boolean = true // boolean
let e: true = true // true
let f: true = false // Error TS2322: 'false' no es asignable a 'true'.

Info

El tipo true (literal) es más restrictivo que boolean: además de exigir un booleano, exige que su valor sea exactamente true. Los tipos literales son una herramienta poderosa para modelar estados precisos.

number y bigint

number cubre enteros, flotantes, Infinity, NaN y valores positivos y negativos:

let a = 1234 // number
const c = 5678 // 5678 (literal)
let e: number = 100 // number
let f: 26.218 = 26.218 // 26.218 (literal)
let g: 26.218 = 10 // Error TS2322

Un number representa con precisión hasta 2^53. Para enteros mayores existe bigint:

let a = 1234n // bigint
const b = 5678n // 5678n
let e = 88.5n // Error TS1353: un literal bigint debe ser entero.
let h: bigint = 100 // Error TS2322: '100' no es asignable a 'bigint'.

string

let a = 'hello' // string
const c = '!' // '!' (literal)
let e: string = 'zoom' // string
let f: 'john' = 'john' // 'john' (literal)
let g: 'john' = 'zoe' // Error TS2322

symbol

Un symbol representa un identificador único. Se crea con Symbol() y admite una descripción opcional útil para depurar:

let id = Symbol("id"); // symbol con descripción "id"

La garantía clave: dos símbolos nunca son iguales, aunque compartan descripción. La descripción es solo una etiqueta sin efecto sobre la identidad.

let id1 = Symbol("id");
let id2 = Symbol("id");
console.log(id1 === id2); // false

let d = id1 + 'x' // Error TS2469: el operador '+' no aplica a 'symbol'.

Objetos

Hay dos formas de tipar objetos. La primera usa la palabra clave object, que solo garantiza que el valor no es null pero no expone sus propiedades, porque TypeScript no sabe qué objeto es:

let a: object = { b: 'x' }
// a.b // Error: la propiedad 'b' no existe en el tipo 'object'

La segunda —y recomendada— describe la forma exacta del objeto:

let c: {
 firstName: string
 lastName: string
} = {
 firstName: 'john',
 lastName: 'barrowman'
}

Las definiciones de objeto admiten campos opcionales (?), índices dinámicos y propiedades de solo lectura:

let a: {
 b: number // obligatorio, number
 c?: string // opcional, string
 [key: number]: boolean // cualquier clave numérica → boolean
}

let user: {
 readonly firstName: string
} = { firstName: 'abby' }

user.firstName = 'abbey' // Error TS2540: propiedad de solo lectura.

Tip

Evita tipar con el objeto vacío {}. Acepta cualquier valor distinto de null o undefined (incluso números o arreglos), lo que vacía de sentido la anotación.

Alias de tipo

Los alias asignan un nombre semántico a un tipo, mejorando la legibilidad sin alterar la verificación:

type Age = number

type Person = {
 name: string
 age: Age
}

let driver: Person = {
 name: 'James May',
 age: 55
}

Como Age es solo un alias de number, sigue siendo compatible con cualquier number. Ten presente que un alias solo puede declararse una vez por ámbito; aplica las mismas reglas de shadowing que let, const y var.

Tipos unión e intersección

Recurriendo a la teoría de conjuntos: la unión (|) admite uno u otro tipo —o ambos—, mientras que la intersección (&) exige cumplir simultáneamente todas las formas combinadas.

flowchart LR
 subgraph Union["A | B"]
 U[Cualquier valor que sea A, B o ambos]
 end
 subgraph Inter["A & B"]
 I[Solo valores que cumplen A y B a la vez]
 end

type Cat = { name: string, purrs: boolean }
type Dog = { name: string, barks: boolean, wags: boolean }

type CatOrDogOrBoth = Cat | Dog // unión
type CatAndDog = Cat & Dog // intersección

Un valor Cat | Dog puede ser un gato, un perro o un objeto que cumpla ambas formas. Un valor Cat & Dog, en cambio, está obligado a tener name, purrs, barks y wags al mismo tiempo.

Arreglos

let a = [1, 2, 3] // number[]
let d = [1, 'a'] // (string | number)[]
let h: number[] = []
h.push(1) // OK
h.push('red') // Error TS2345

Un arreglo declarado vacío sin anotación arranca como any[] y va ampliando su tipo según lo que insertes —otra razón para anotar explícitamente las colecciones en las fronteras del sistema.

Tuplas

Las tuplas son un subconjunto de los arreglos con longitud fija y tipos posicionales:

let a: [number] = [1]

// [nombre, apellido, año de nacimiento]
let b: [string, string, number] = ['malcolm', 'gladwell', 1963]

b = ['queen', 'elizabeth', 'ii', 1926] // Error TS2322: posición/longitud inválida

También admiten posiciones opcionales:

// Tarifas de tren que a veces varían según la dirección
let trainFares: [number, number?][] = [
 [3.75],
 [8.25, 7.70],
 [10.50]
]

Conclusión

El sistema de tipos de TypeScript va mucho más allá de etiquetar variables: distingue entre any (inseguro) y unknown (seguro), modela estados exactos con tipos literales, compone formas mediante uniones e intersecciones y garantiza estructuras rígidas con tuplas. Dominar este catálogo es el prerrequisito para los temas avanzados de la serie.

En el siguiente artículo aplicaremos estos fundamentos a los objetos y tipos personalizados, donde los alias de tipo se vuelven el centro del diseño.

TypeScript: Introducción y configuración del entorno

Dacadev — Sun, 14 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Este artículo abre la serie sobre TypeScript. Aquí analizaremos qué problema resuelve el tipado estático, cómo opera el compilador tsc y cómo dejar listo un proyecto profesional con tsconfig.json.

JavaScript resuelve los tipos en tiempo de ejecución. Esto significa que un error tan trivial como pasar un string donde se esperaba un number solo se manifiesta cuando el código ya está corriendo, frecuentemente en producción y bajo la forma de un NaN silencioso o una excepción difícil de rastrear. TypeScript ataca este problema en la raíz: agrega un sistema de tipos estático sobre JavaScript que traslada la detección de errores desde el runtime hacia el tiempo de compilación.

¿Cómo se ejecuta el código? AST, bytecode y runtime

Para entender qué aporta TypeScript conviene recordar el ciclo de vida de un programa en un motor de JavaScript:

El programa se parsea hacia un AST (Abstract Syntax Tree).
El AST se compila a bytecode.
El bytecode es evaluado por el runtime.

TypeScript se inserta antes de este flujo. El compilador tsc toma tu código .ts, construye su propio AST, lo somete al typechecker y, si todo es válido, emite JavaScript estándar que cualquier motor puede ejecutar.

flowchart LR
 A[Código TypeScript] --> B[AST de TypeScript]
 B --> C{Typechecker}
 C -- válido --> D[JavaScript emitido]
 C -- error --> E[Error en compilación]
 D --> F[AST de JavaScript]
 F --> G[Bytecode]
 G --> H[Runtime]

La conclusión clave: el typechecker es una capa de verificación que se ejecuta antes de generar el JavaScript final. Los errores de tipo nunca llegan al runtime porque la compilación se detiene antes.

El sistema de tipos

TypeScript admite tanto anotaciones de tipo explícitas como inferencia automática. Ambas estrategias coexisten en el mismo archivo:

let a: number = 1 // a es number
let b: string = 'hello' // b es string
let c: boolean[] = [true, false] // c es un arreglo de booleanos

let a = 1 // a es number (inferido)
let b = 'hello' // b es string (inferido)
let c = [true, false] // c es boolean[] (inferido)

Tip

Apóyate en la inferencia siempre que el tipo sea evidente y reserva las anotaciones explícitas para las fronteras del sistema: firmas de funciones, APIs públicas y estructuras de datos compartidas. Esto reduce el ruido sin sacrificar seguridad.

La diferencia esencial frente a JavaScript se resume así:

Característica del sistema de tipos	JavaScript	TypeScript
¿Cómo se enlazan los tipos?	Dinámicamente	Estáticamente
¿Se convierten automáticamente?	Sí	No (en general)
¿Cuándo se verifican?	En tiempo de ejecución	En tiempo de compilación
¿Cuándo afloran los errores?	En ejecución	En compilación

Instalación de TypeScript

TypeScript se distribuye como un paquete de Node, por lo que necesitas tener Node.js instalado. Inicializa el proyecto y agrega las dependencias de desarrollo:

npm init -y
npm install --save-dev typescript @types/node

@types/node aporta las definiciones de tipos del entorno de ejecución de Node, indispensables si vas a trabajar en el backend.

tsconfig.json: el corazón de la configuración

El archivo tsconfig.json, ubicado en la raíz del proyecto, define cómo el compilador interpreta y transforma tu código. Una configuración base sólida luce así:

{
 "compilerOptions": {
 "lib": ["es2015"],
 "module": "commonjs",
 "outDir": "dist",
 "sourceMap": true,
 "strict": true,
 "target": "es2015"
 },
 "include": ["src"]
}

Cada opción cumple un rol concreto:

include: indica las rutas donde tsc debe buscar los archivos a compilar.
lib: declara qué librerías de tipos (APIs del entorno) asume disponibles el proyecto.
module: define el sistema de módulos del código emitido (commonjs, esnext, etc.).
outDir: ubicación de los archivos JavaScript compilados.
sourceMap: genera source maps para depurar el TypeScript original desde el navegador o Node.
strict: habilita el conjunto completo de comprobaciones estrictas. Es la opción que más valor aporta.
target: versión de JavaScript a la que se transpila el código.

Puedes consultar el catálogo completo de opciones en la documentación oficial de tsc, o explorarlas desde la terminal:

npx tsc --help

Warning

La opción strict no es opcional en un proyecto serio. Activarla desde el primer commit evita una migración dolorosa más adelante, cuando el código ya arrastra cientos de tipos implícitos any.

El archivo de entrada: index.ts

El punto de entrada convencional es src/index.ts. Comencemos con el clásico mensaje de prueba:

console.log('hello world from TS!')

Compila el proyecto y ejecútalo:

npx tsc
node ./dist/index.js

tsc lee la configuración de tsconfig.json, transpila todo lo que esté bajo src y deposita el resultado en dist.

Hola mundo y la verificación de tipos en acción

Observemos cómo el typechecker protege contra asignaciones inválidas:

let msg: string = 'Hola mundo';
console.log(msg);
msg = 'David Casas';
console.log(msg);
// msg = 123 // Error: number no es asignable a string

Al compilar, TypeScript transpila a JavaScript plano eliminando las anotaciones:

var msg = 'Hola mundo';
console.log(msg);
msg = 'David Casas';
console.log(msg);

El tipo string desaparece del código emitido porque su único propósito era validar en compilación. Esta propiedad —los tipos se borran tras la verificación— se conoce como type erasure.

Watch mode: compilación continua

Compilar manualmente tras cada cambio rompe el flujo de trabajo. El compilador incluye un modo observador que recompila de forma incremental cada vez que detecta una modificación:

npx tsc --watch
# o su forma corta
npx tsc -w

Mantén este proceso abierto en una terminal mientras desarrollas: cada vez que guardes un archivo .ts, verás de inmediato los errores de tipo o la salida actualizada en dist.

Conclusión

TypeScript no reemplaza a JavaScript; lo eleva añadiendo una capa de verificación estática que captura errores antes de ejecutar una sola línea. Con Node instalado, un tsconfig.json en modo strict y el compilador en watch mode, ya tienes un entorno profesional listo para los siguientes temas de la serie.

En el próximo artículo profundizaremos en los tipos básicos del lenguaje: any, unknown, number, string, symbol, objetos, uniones e intersecciones.