Un sistema de interfaz compartido entre todas mis aplicaciones

Problema

Los componentes de interfaz vivían dentro del portfolio. Con una segunda aplicación en camino, la única forma de reutilizarlos era copiarlos — y dos copias del mismo botón dejan de ser el mismo botón en cuanto alguien arregla algo en una sola.

No es un problema estético. Es que cada arreglo hay que hacerlo N veces y acordarse de las N.

Decisión

Un paquete privado, publicado y versionado, en lugar de meter todas las aplicaciones en un mismo repositorio. La alternativa del monorepo evita publicar y permite cambios atómicos, pero obliga a que cada proyecto viva en el mismo repositorio, y no todos pueden.

La regla que decide qué entra: si un componente necesita una prop específica de una aplicación para funcionar, todavía no está listo para compartirse. Se queda donde está hasta que un segundo proyecto lo pida igual. Sin esa regla, la librería acaba llena de componentes con quince propiedades para cubrir tres casos.

Implementación

Veintinueve primitivos y ciento ocho tokens de diseño. Los tokens son la parte que más iguala dos productos: los componentes se pueden cambiar, pero si el color, el radio y la tipografía coinciden, dos aplicaciones distintas siguen pareciendo de la misma casa.

Se publica como código fuente TypeScript, sin compilar, y el consumidor lo transpila. Así no hay dos pasos de compilación que mantener sincronizados ni un artefacto que pueda quedarse viejo respecto al código.

La directiva de componente cliente se pone solo donde hace falta: diez de los veintinueve siguen siendo de servidor. Marcarlos todos como cliente habría sido más rápido y habría metido JavaScript en cada página que los usa.

El token de lectura del registro entra en los contenedores como secreto de construcción, no como argumento: un argumento queda grabado en las capas de la imagen y lo lee cualquiera que la descargue.