Cómo contribuir en la Plataforma Regional
Esta sección explica cómo colaborar de forma segura y consistente en el repositorio apolo-app-platcom-platform, alineado con las prácticas de Cencosud en materia de calidad, seguridad y compliance.
Antes de abrir un pull request, asegúrate de:
1. Entender el contexto del proyecto
- Revisar la documentación de:
2. Trabajar siempre en ramas de feature
- Nunca desarrolles directamente sobre
main. - Crea ramas siguiendo la convención definida en Estrategia de ramas.
3. Mantener el estilo de código y convenciones
- Respeta el estándar de ESLint + Prettier descrito en Estilo de código.
- Usa mensajes de commit con Commitizen / Conventional Commits, descrito en Commits.
4. Asegurar calidad mínima antes de abrir un PR
- Ejecutar linters y formatters.
- Correr pruebas relevantes.
- Actualizar documentación cuando afectes comportamientos visibles.
Flujo general para contribuir
1. Crear una rama a partir de main:
git checkout main
git pull origin main
git checkout -b feature/<resumen-corto>
2. Desarrollar la funcionalidad o corrección
- Añadir tests cuando aplique.
- Mantener el código modular (libs, dominios, bounded contexts).
3. Validar localmente
# Lint del proyecto afectado
npx nx lint <proyecto>
# Pruebas del proyecto afectado
npx nx test <proyecto>
# Formateo si es necesario
npx nx format:write
4. Crear el Pull Request
- Descripción clara de:
- Qué problema se resuelve
- Qué cambios se introducen
- Cómo probarlos
- Adjuntar capturas de pantalla si se modifican flujos de UI.
Buenas prácticas generales
- Pequeños PRs: Es mejor varios cambios pequeños y revisables que un PR gigante difícil de aprobar.
- Nombre de ramas descriptivo: Usa prefijos como
feature/,fix/,chore/,docs/. - Mantén el foco: Un PR debería atacar un solo objetivo (feature, fix, refactor, etc.).
- Actualiza docs: Si cambias contratos de API, flujos críticos o arquitectura, revisa:
docs/apidocs/architecturedocs/development
Para detalles específicos revisa: