Monorepos Multi-Dominio

Monorepos Multi-Dominio

Ejecutar más de un sitio independiente desde un único repositorio git - digamos, un sitio de marketing y un sitio de documentación separado, o un puñado de sitios de producto que por conveniencia comparten un repositorio - no necesita nada especial de bxSites. Cada sitio es simplemente su propia raíz de proyecto: su propio bxsites.yaml más su propia carpeta de contenido, construida, servida y desplegada de forma independiente apuntando bxSites a esa única carpeta. Un "monorepo con varios dominios" es sencillamente un repositorio que contiene varias de estas raíces de proyecto, una junto a la otra.

El patrón

La propia ubicación de bxsites.yaml es siempre donde sea que apunte la raíz de proyecto explícita de la CLI - el directorio de trabajo actual, o un --projectRoot=<path> explícito (o una ruta posicional simple). No hay ninguna búsqueda ascendente de directorios ni ningún concepto separado de "raíz del repositorio" frente a "raíz del proyecto" - cada verbo simplemente resuelve una raíz de proyecto por invocación y busca bxsites.yaml (o .yml/.toml/.json) directamente dentro de ella. Un monorepo con varios dominios no es más que un repositorio que contiene varias de estas, cada una completamente independiente:

my-monorepo/
├── marketing/
│   ├── bxsites.yaml        ← source: .  (o docs - decisión propia de marketing)
│   ├── index.md
│   ├── about.md
│   └── .theme/               ← sobrescritura de tema propia de marketing, si la tiene
└── docs-site/
    ├── bxsites.yaml        ← source: docs
    └── docs/
        ├── index.md
        ├── guides/
        └── .theme/            ← sobrescritura de tema propia de docs-site, si la tiene

Cada uno de marketing/ y docs-site/ arriba es un proyecto bxSites completo y autocontenido - su propio bxsites.yaml, su propia raíz de contenido (resuelta por la propia clave source de ese proyecto, o por autodetección - consulta Origen del Contenido), y su propia sobrescritura .theme/.themes viviendo dentro de esa raíz de contenido. Nada de esto es nuevo ni específico de monorepos; es el mismo comportamiento de una-sola-raíz-de-proyecto que bxSites siempre ha tenido, solo que con más de una raíz de proyecto guardada en el mismo repositorio.

Anídalas de la forma que mejor convenga al repositorio - hermanas en la raíz (como arriba), bajo un sites/ compartido, o donde sea que tenga más sentido; a bxSites solo le importa la ruta que le pases mediante --projectRoot, no dónde esté esa ruta en relación con el resto del repositorio.

Construir un dominio

Apunta --projectRoot (o una ruta posicional simple) a la raíz de proyecto que quieras construir - todos los verbos lo aceptan, no solo build:

bxSites build --projectRoot=marketing
bxSites build --projectRoot=docs-site

Cada comando resuelve su propio bxsites.yaml, su propia raíz de contenido, y su propia sobrescritura de tema de forma totalmente independiente - construir marketing/ nunca toca el site/ de salida, la configuración, ni el tema de docs-site/, y viceversa. No hay ningún paso de construcción compartido ni ningún requisito de orden entre dominios; construye los dominios que hayan cambiado, en el orden que prefieras.

Previsualizar un dominio

serve funciona de la misma forma - previsualiza exactamente una raíz de proyecto a la vez:

bxSites serve --projectRoot=docs-site

Para previsualizar un dominio distinto, detén serve y vuelve a ejecutarlo con un --projectRoot diferente (o desde un directorio de trabajo distinto). Dos dominios que necesiten previsualización en vivo al mismo tiempo solo necesitan dos procesos serve separados, cada uno con su propio --projectRoot y (si se ejecutan simultáneamente) su propio --port.

Construir todos los dominios en CI

Como cada dominio es una invocación independiente de bxSites build --projectRoot=<path>, CI simplemente recorre en bucle la lista de raíces de proyecto:

name: Build sites
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        project: [marketing, docs-site]
    steps:
      - uses: actions/checkout@v4
      - name: Install BoxLang + bx-sites
        run: |
          /bin/bash -c "$(curl -fsSL https://install.boxlang.io)"
          export BOXLANG_INSTALL_HOME="/usr/local/boxlang"
          export PATH="/root/.boxlang/bin:/usr/local/bin:$PATH"
          install-bx-module bx-sites
      - name: Build ${{ matrix.project }}
        run: bxSites build --projectRoot=${{ matrix.project }}
      - uses: actions/upload-artifact@v4
        with:
          name: site-${{ matrix.project }}
          path: ${{ matrix.project }}/site/

Un bucle bash simple funciona igual de bien fuera de una construcción con matriz, y hace fácil fallar todo el job en cuanto un dominio falla al construirse:

for project in marketing docs-site; do
	echo "Building $project..."
	bxSites build --projectRoot="$project" || exit 1
done

La propia salida site/ de cada dominio se despliega de la misma forma en que se despliega la de un proyecto de un solo sitio - consulta Despliegue - solo que una vez por dominio, apuntando a los propios deployments/*.json de ese dominio y a su propia carpeta <project>/site/.

Sin colisión entre dominios

Como .theme/.themes viven dentro de la propia raíz de contenido de cada dominio (consulta Origen del Contenido: Dónde vive una sobrescritura de tema) en lugar de en una raíz de proyecto compartida y desnuda, dos dominios en el mismo monorepo pueden cada uno llevar su propia sobrescritura de tema sin ningún riesgo de que uno tape al otro - marketing/.theme/ y docs-site/docs/.theme/ son dos carpetas completamente separadas, resueltas de forma independiente por la construcción de cada dominio. Lo mismo aplica a todo lo demás con alcance de proyecto - bxsites.yaml, deployments/*.json, docs/versions/, docs/i18n/ - la propia copia de cada dominio es exactamente la suya, sin nada compartido a menos que decidas programar tú mismo ese compartir (por ejemplo, copiando un archivo extraCss común a cada dominio antes de construir).