Contribuir
FDS es open source. Las contribuciones son bienvenidas: issues, PRs, ejemplos, correcciones de documentación.
Repositorio
- GitHub: github.com/flowtitude/flowtitude-design-system
- Issues: reporta bugs o propón mejoras con contexto reproducible.
- Pull requests: sigue las convenciones del proyecto (ver más abajo).
Cómo reportar un bug
- Busca si el issue ya existe.
- Crea un issue con:
- Versión de FDS usada.
- Entorno (Vite, Next, WordPress+WindPress).
- Versión de Tailwind.
- Código mínimo que reproduce el problema.
- Capturas si es un bug visual.
Cómo proponer una mejora
- Abre un issue con la propuesta antes de empezar el PR.
- Argumenta por qué no lo resuelve Tailwind estándar.
- Espera feedback antes de escribir código.
Reglas para PRs
| Regla | Detalle |
|---|---|
| Tokens con prefijo | --ft-* (knobs) o --spacing-*, --radius-* (semánticos). |
| Colores en OKLCH | Nunca HEX ni RGB en el @theme. |
| Sin media queries | Todo fluido con clamp(). |
@apply | Solo en components y base. Nunca en utilities. |
| Orden de layers | Respetar theme, base, layouts, components, utilities, custom. |
| Naming de componentes | .btn-*, .card-*, .badge-* (prefijo por componente). |
Estilo de código
- CSS: sin minificación, comentado donde no sea obvio.
- Indentación: 2 espacios.
- Saltos de línea entre bloques lógicos.
Cómo empezar en local
git clone https://github.com/flowtitude/flowtitude-design-system.git
cd flowtitude-design-system
# no hay build: abre main.css directamente en tu proyecto
Para probar en un proyecto Tailwind 4:
@import "tailwindcss";
@import "./ruta/a/flowtitude-design-system/main.css";
Documentación
Si tu PR afecta a tokens, componentes, layouts o utilidades, actualiza la página correspondiente en docs/src/app/docs/ del repositorio.
Ejecuta el build del doc site antes de enviar el PR:
cd docs
npm run build
Filosofía antes que features
Un componente nuevo en FDS no entra solo por ser "útil". Debe encajar con la filosofía del sistema: tokens primero, fluido sin media queries, composición sobre configuración. Si no encaja, probablemente tenga más sentido como componente de proyecto (FlowKit, BricksShift u otro).
Código de conducta
Respeto mutuo, feedback técnico y crítica constructiva. Lo esperable en cualquier proyecto open source sano.
Licencia
Las contribuciones se incorporan bajo la licencia del proyecto (ver Changelog para el estado actual de la licencia formal).