TypeScript para principiantes: 7 errores fatales y cómo evitarlos

Introducción: por qué TypeScript muerde a los principiantes, o cómo no fracasar en tu primer proyecto

¿Alguna vez has sentido que TypeScript es como un profesor estricto que te pone un cero por cualquier tontería? Si es así, bienvenido al club. Uno de cada dos principiantes que pasan de JavaScript a TypeScript comete los mismos errores. Y es normal: TypeScript es realmente más difícil, requiere disciplina y comprensión de los tipos.

Pero hay una buena noticia: la mayoría de los errores al aprender TypeScript se pueden predecir y prevenir. En este artículo he recopilado los 7 errores más comunes que cometen los desarrolladores principiantes. Analizaremos cada error con ejemplos de código, explicaremos por qué es malo y mostraremos cómo hacerlo correctamente.

Si acabas de empezar a aprender TypeScript o ya te has llevado algún que otro golpe, este artículo te ahorrará horas de depuración y nervios. ¡Allá vamos!

Error n.º 1: Uso descontrolado de any (la fuente de todos los males)

Qué hacen los principiantes

El error más común entre quienes aprenden TypeScript es escribir any en todas partes. Piensan: «Bueno, no especifiqué el tipo, ¡pero el código funciona!».

// ❌ Mal: any mata toda la utilidad de TypeScript\nfunction processData(data: any) {\n    console.log(data.name.toUpperCase());\n    return data.price * 2;\n}\n\nconst result = processData({ name: "portátil", price: 500 });\n// Todo funciona... hasta que le pasas null\nprocessData(null); // ¡Error en tiempo de ejecución!

Por qué es un error

any es un agujero negro en TypeScript. Cuando escribes any, le dices al compilador: «Apártate, yo me encargo». Y él se aparta. Pierdes el autocompletado, la verificación de tipos y la protección contra errores tontos. TypeScript se convierte de nuevo en JavaScript, con todas sus desventajas.

Cómo solucionarlo

Usa tipos concretos. Si el tipo no se conoce de antemano, unknown es tu amigo. Te obligará a verificar los datos antes de usarlos.

// ✅ Bien: tipos concretos y unknown\nfunction processData(data: { name: string; price: number }) {\n    console.log(data.name.toUpperCase());\n    return data.price * 2;\n}\n\n// O si el tipo realmente es desconocido:\nfunction safeProcess(data: unknown) {\n    if (typeof data === 'object' && data !== null && 'name' in data) {\n        // Ahora TypeScript sabe que data es un objeto con el campo name\n        console.log((data as { name: string }).name);\n    }\n}

Consejo: Activa la regla no-explicit-any en ESLint: no te permitirá usar any sin una razón de peso.

Error n.º 2: Ignorar el strict mode (o «por qué todo funciona, pero no como debería»)

Qué hacen los principiantes

Muchos desarrolladores principiantes al aprender TypeScript desactivan el modo estricto en tsconfig.json o ni siquiera lo activan. Piensan: «así vale, menos errores de compilación».

// ❌ Mal: strict: false\n// tsconfig.json\n{\n    "compilerOptions": {\n        "strict": false, // ¡Error!\n        "noImplicitAny": false,\n        "strictNullChecks": false\n    }\n}\n\n// Ahora este código se compilará sin errores:\nfunction greet(name: string | null) {\n    console.log(name.toUpperCase()); // ¡Posible null!\n}\ngreet(null); // Runtime error: Cannot read properties of null

Por qué es un error

Sin el modo estricto, TypeScript pierde la mitad de su potencia. No recibes advertencias sobre posibles null y undefined, no verificas los tipos de los argumentos y, al final, terminas con errores en producción.

Cómo solucionarlo

Activa siempre strict: true. Esto activa todas las comprobaciones estrictas de una vez.

// ✅ Bien: strict: true\n{\n    "compilerOptions": {\n        "strict": true,\n        "target": "ES2020",\n        "module": "ESNext"\n    }\n}\n\n// Ahora TypeScript te obligará a manejar el null:\nfunction g