Errores reales descubiertos al añadir TypeScript estricto a un proyecto JavaScript

Conclusión
El proyecto kimura512.dev nació en JavaScript y migró posteriormente a TypeScript estricto. Incorporar tipos estáticos a posteriori no inventa funciones mágicas, sino que desvela premisas erróneas que permanecían latentes en tiempo de ejecución. Mientras el compilador mostraba errores, congelé los despliegues y separé los commits de corrección de los de nuevas funcionalidades.
1. Detección de claves de traducción omitidas
Las cadenas multilingües se centralizaban en un archivo único, pero las omisiones pasaban inadvertidas hasta la navegación real. Con Record<Language, string>, cualquier traducción incompleta interrumpe la compilación al instante.
2. Robustez en enlaces Markdown opcionales
La lógica de análisis de enlaces asumía que la dirección siempre estaba informada. Al reflejar en el tipado que href puede ser nulo, se implementó una gestión defensiva que evita bloqueos inesperados.
3. Homogeneización de marcas de fecha ISO
Antiguos registros contenían formatos de fecha heterogéneos que en ciertos navegadores provocaban Invalid Date. Definir un contrato de datos estricto resolvió estas inconsistencias en fase de desarrollo.
4. Supresión de aserciones de tipo frágiles
Sustituí las aserciones ciegas con as por esquemas de validación en la entrada de las rutas de API, rechazando datos anómalos antes de que contaminaran la lógica interna.
5. Actualización de referencias en React
El paso a versiones modernas exigió inicializar explícitamente useRef y acotar ReactNode, eliminando advertencias y comportamientos anómalos.
6. La compilación como cortafuegos definitivo
Comprobar que vinext build finaliza sin advertencias antes de cada subida constituye la mejor salvaguarda de calidad en proyectos personales.
7. Variantes de componentes como tipos unión
Definir variantes de diseño mediante uniones de cadenas literales impide asignar nombres obsoletos o erróneos a los componentes visuales.
8. Aislamiento de commits de refactorización
Los cambios de tipado se aíslan siempre de las modificaciones estéticas para facilitar auditorías y revisiones de código.
Resumen
Blindar los límites de entrada de datos estabiliza el comportamiento global con un esfuerzo de cambio mínimo.
Notas operativas
Q. ¿Se activó el modo estricto en un solo paso?
No; se fueron habilitando reglas progresivamente a lo largo de varias semanas.
Q. ¿Se erradicó por completo el uso de 'any'?
Salvo en envoltorios de librerías externas que usan unknown, el código propio está tipado al cien por cien.