Aburrido a propósito: cómo elegimos versiones
Solo versiones estables, versiones exactas y menos piezas móviles: las reglas poco vistosas detrás de un software que sigue compilando un año después.
Todo proyecto empieza con una lista de decisiones que nadie notará si las tomamos bien: qué entorno de ejecución, qué base de datos, qué versión de cada librería. Las decidimos siempre igual, y dejamos las reglas por escrito. Este sitio se construyó con ellas.
Solo versiones estables
Usamos la última versión estable de cada herramienta, no la más nueva. Cuando se construyó este sitio, había disponible una nueva versión mayor de nuestra herramienta de base de datos como candidata a versión final, y acababa de salir una nueva versión mayor de TypeScript sin soporte todavía en los linters y ejecutores de pruebas que usamos. Nos quedamos en las versiones estables anteriores de ambas, y cambiaremos cuando las herramientas de alrededor estén listas.
El entorno de ejecución sigue la misma regla: la versión actual de soporte a largo plazo de Node.js, no la que todavía está esperando a serlo.
Versiones exactas, sin rangos
Cada dependencia está fijada a una versión exacta. Sin ^ ni ~. Un rango significa que el código que se ejecuta en el servidor puede ser distinto del que se probó la semana pasada sin que nadie haya cambiado nada. Con versiones exactas y el archivo de bloqueo en el repositorio, una actualización es siempre un cambio deliberado con su propia revisión, y una compilación de hace seis meses se puede reproducir.
Menos piezas móviles
Para los estilos usamos módulos CSS y una lista corta de tokens de diseño en lugar de un framework de CSS. Para la validación, un único esquema describe cada dato, y de ese mismo esquema salen la comprobación en ejecución, el tipo de TypeScript y la documentación de la API.
Cada una de estas decisiones elimina algo que podría desincronizarse.
Por qué le importa a un cliente
Nada de esto se ve en una demo. Se ve un año después, cuando la aplicación necesita una función nueva y quien la añade encuentra un código que todavía se instala, todavía compila y todavía se comporta como dicen las pruebas. A eso nos referimos cuando decimos que construimos cosas para durar.