Tipado en JavaScript sin migrar a TypeScript

Migrar un proyecto de JavaScript a TypeScript tiene beneficios claros y un costo alto: renombrar archivos, tipar todo, ajustar la compilación y detener otras tareas mientras tanto. Hay un camino intermedio que da buena parte del beneficio en una tarde. Lo apliqué a seis proyectos de Node.js con PostgreSQL y frontends en React y Vue.

Por qué importa más de lo que parece

El detonante fue una pregunta práctica: ¿qué extensiones del editor ayudan de verdad a detectar errores? Un tema de colores o un paquete de íconos no aportan nada a la calidad del código. Lo que sí aporta son las herramientas que producen diagnósticos: errores y advertencias que aparecen en el editor, se pueden revisar en lote y también los leen los asistentes de programación que trabajan sobre el proyecto. Sin configuración, un proyecto en JavaScript plano casi no genera ninguno.

Los cuatro archivos

Cada paquete, backend y frontend por separado, recibe su propia configuración.

• Configuración de ESLint en formato plano, con las reglas recomendadas y pocas reglas adicionales.
• Un jsconfig.json con verificación de tipos sobre JavaScript activada, sin emitir archivos y en modo no estricto.
• Paquetes de tipos como dependencias de desarrollo para Node, Express y las librerías principales.
• Scripts en el package.json para correr el linter y la verificación de tipos desde la terminal y la integración continua.

El segundo archivo es el importante. Convierte al servidor de lenguaje de TypeScript en un verificador de tipos sobre archivos .js: detecta propiedades que no existen, argumentos faltantes y valores que pueden ser nulos, sin cambiar una sola extensión.

Ajustes según el tipo de proyecto

• Backend con CommonJS: módulo de tipo CommonJS.
• Backend con módulos ES: resolución de módulos de Node moderna.
• Frontend con Vite: módulos ES, resolución tipo bundler y JSX configurado.
• Con dependencias nativas: limitar la profundidad con la que se analiza JavaScript dentro de las dependencias, para no recibir errores de código ajeno.

Reglas que dan falsos positivos

Una configuración que llena el editor de avisos irrelevantes se termina ignorando. Algunas reglas se ajustaron a nivel de proyecto:

• Actualizaciones atómicas: se desactivó. Salta con el patrón normal de un middleware de Express que asigna datos a la petición después de una espera, que no es un error.
• Variables sin usar: se ignoran los nombres que empiezan con guion bajo y las propiedades restantes de una desestructuración, un patrón común para quitar campos sensibles de un objeto.
• Vue: se usó el conjunto esencial de reglas y no el recomendado, que agrega reglas de formato. En un proyecto generó 339 advertencias de formato que tapaban las que importaban. El formato es trabajo de un formateador, no del linter.

Bugs reales en la primera pasada

Las reglas nuevas de hooks de React destaparon problemas reales, como estados actualizados dentro de efectos de una forma que provoca renders de más. La recomendación con estos casos: si el arreglo correcto exige probar la aplicación, no se adivina. Se deja la regla como advertencia con un comentario que explica por qué, en vez de dejar el linter en rojo permanente o aplicar un cambio a ciegas.

Cuándo sí migrar

Este camino es suficiente para proyectos pequeños y medianos, o como primer paso. Si el proyecto crece, tiene varios desarrolladores o expone una librería con tipos públicos, TypeScript completo compensa su costo. Mientras tanto, cuatro archivos dan diagnósticos reales a cambio de casi nada.