KompKit: Diseñando un Kit de Utilidades Cross-Platform como Monorepo

KompKit no empezó como una app. Empezó como un problema que seguía resolviendo una y otra vez.

Pequeñas funciones de utilidad — validación de email, debouncing, formateo — reescritas en cada proyecto, ligeramente diferentes cada vez, a través de codebases web y Android.

KompKit es mi intento de dejar de hacer eso.

Un Kit de Utilidades, No un Framework

KompKit es intencionalmente pequeño en alcance.

No es un framework. No intenta abstraer las plataformas. No introduce una nueva forma de construir apps.

Se enfoca en una sola cosa:

Proporcionar APIs de utilidades idénticas y predecibles a través de Web (TypeScript) y Android (Kotlin).

Sin magia. Sin trucos en runtime. Solo comportamiento bien definido.

Por Qué un Monorepo

Un monorepo fue una elección deliberada.

KompKit vive en un único repositorio porque:

  • Las APIs deben evolucionar juntas
  • La documentación debe mantenerse sincronizada
  • La paridad de comportamiento importa más que la velocidad de release

Cada plataforma tiene su propia implementación, pero comparten la misma intención.

Esto hace las diferencias explícitas en lugar de ocultas.

Específico de Plataforma, API Idéntica

KompKit no comparte código fuente entre plataformas.

En su lugar, comparte contratos.

Las implementaciones de TypeScript y Kotlin están escritas nativamente, usando:

  • TypeScript + Node.js en Web
  • Kotlin JVM + Coroutines en Android

Lo que permanece idéntico es:

  • Nombres de funciones
  • Parámetros
  • Comportamiento
  • Casos límite

Si isEmail() se comporta de cierta manera en Web, se comporta igual en Android.

Esa consistencia es el verdadero producto.

Estructura por Responsabilidad

El repositorio está organizado por plataforma y responsabilidad:

packages/
└── core/
    ├── web/       # Implementación TypeScript
    └── android/   # Implementación Kotlin JVM

Documentación, CI y herramientas viven en la raíz.

Esto mantiene la lógica de plataforma aislada mientras hace las decisiones cross-platform inevitables — de una buena manera.

Herramientas como Ciudadano de Primera Clase

KompKit está construido con herramientas modernas desde el día uno:

  • TypeScript 5.6+
  • Kotlin 2.1+
  • Cobertura completa de tests
  • Pipelines de CI por plataforma
  • Documentación de API generada (TypeDoc + Dokka)

Esto no es accidental.

Si una librería de utilidades está destinada a ser reusada, debe ser aburrida, predecible y confiable.

Open Source como Restricción

KompKit es open source por diseño.

Eso fuerza:

  • Nombrado claro
  • Decisiones explícitas
  • Menos atajos
  • Mejor documentación

Escribir código del que otros podrían depender cambia cómo abordas incluso la función helper más pequeña.

Dónde Encaja Flutter

Aunque KompKit actualmente apunta a Web y Android, ya está influyendo en cómo pienso sobre Flutter.

Las apps de Flutter a menudo terminan reimplementando la misma lógica de validación y formateo que se encuentra en otros lugares.

Tener un núcleo bien definido de utilidades compartidas hace más fácil:

  • Mantener el comportamiento consistente entre productos
  • Reducir lógica duplicada
  • Tratar Flutter como consumidor, no como dueño, de las reglas de negocio

Flutter no es la base aquí — es un cliente.

Y esa separación importa.

Pensamientos Finales

KompKit todavía está en alpha, y eso es intencional.

Ahora mismo, el objetivo no es la cantidad de features. Es corrección, claridad y consistencia.

Si KompKit tiene éxito, no será porque hace mucho. Será porque hace unas pocas cosas extremadamente bien, a través de plataformas, sin sorpresas.

Ese es el tipo de base que vale la pena construir.