sass-template-common 0.16.9 → 0.16.11

package/README.md

@@ -1,36 +1,36 @@
-# sass-template-common
-
-Librería web, maqueta de configuración y componentes para proyectos sass.
-
-## Publicar nueva versión
-
-Para que los cambios se reflejen al publicar:
-
-1. **Subir versión** (obligatorio; si no, npm rechaza o se usa la misma versión):
-   ```bash
-   pnpm version:patch   # 0.3.21 → 0.3.22
-   # o
-   pnpm version:minor   # 0.3.21 → 0.4.0
-   pnpm version:major   # 0.3.21 → 1.0.0
-   ```
-
-2. **Build limpio + publicar**:
-   ```bash
-   pnpm run clean && pnpm run build && pnpm publish
-   ```
-   O en un solo paso (patch):
-   ```bash
-   pnpm release:patch
-   ```
-
-3. **`prepublishOnly`**: Antes de cada `pnpm publish` se ejecuta `clean` + `build`, así siempre se publica un build nuevo.
-
-4. **En proyectos que consumen la lib**: Actualizar la dependencia y reinstalar:
-   ```bash
-   pnpm update sass-template-common
-   # o cambiar la versión en package.json y luego
-   pnpm install
-   ```
-   Si usan versión fija (`"0.3.21"`), hay que actualizarla a la nueva (p. ej. `"0.3.22"`).
-
-**Si no ves los cambios:** comprueba que subiste la versión (`version:patch` o similar), que hiciste `clean` + `build` antes de publicar, y que el proyecto consumidor tiene actualizada la dependencia (o `^0.3.21` y ha ejecutado `pnpm update`).
+# sass-template-common
+
+Librería web, maqueta de configuración y componentes para proyectos sass.
+
+## Publicar nueva versión
+
+Para que los cambios se reflejen al publicar:
+
+1. **Subir versión** (obligatorio; si no, npm rechaza o se usa la misma versión):
+   ```bash
+   pnpm version:patch   # 0.3.21 → 0.3.22
+   # o
+   pnpm version:minor   # 0.3.21 → 0.4.0
+   pnpm version:major   # 0.3.21 → 1.0.0
+   ```
+
+2. **Build limpio + publicar**:
+   ```bash
+   pnpm run clean && pnpm run build && pnpm publish
+   ```
+   O en un solo paso (patch):
+   ```bash
+   pnpm release:patch
+   ```
+
+3. **`prepublishOnly`**: Antes de cada `pnpm publish` se ejecuta `clean` + `build`, así siempre se publica un build nuevo.
+
+4. **En proyectos que consumen la lib**: Actualizar la dependencia y reinstalar:
+   ```bash
+   pnpm update sass-template-common
+   # o cambiar la versión en package.json y luego
+   pnpm install
+   ```
+   Si usan versión fija (`"0.3.21"`), hay que actualizarla a la nueva (p. ej. `"0.3.22"`).
+
+**Si no ves los cambios:** comprueba que subiste la versión (`version:patch` o similar), que hiciste `clean` + `build` antes de publicar, y que el proyecto consumidor tiene actualizada la dependencia (o `^0.3.21` y ha ejecutado `pnpm update`).

package/dist/sass-template-common.d.ts

@@ -1130,6 +1130,7 @@ export declare interface DestacadoDiarioLiveProps extends SectionCardProps, NewD
     banner?: ReactNode;
     banners?: BannerResponse[];
     rightOnlyBanner?: boolean;
+    rightHasBanner?: boolean;
     customSectionCardStyles?: CSSProperties;
     customNewsDescriptionStyles?: CSSProperties;
     customLiveStyles?: CSSProperties;
@@ -1779,10 +1780,12 @@ declare type HeaderProps = {
      * top: 0`) y el contenido lo despeja con un `margin-top` fijo. Un sitio que
      * active `pre_header` DEBE declarar la altura reservada:
      *
-     *     :root { --pre-header-height: 90px; }
+     *     :root { --pre-header-height: 90px; --pre-header-height-mobile: 50px; }
      *
-     * `headers-header-1.css` la suma al margen del contenido. Default `0px`, asi
-     * que sin el slot el layout queda byte-identico.
+     * `headers-header-1.css` la suma al margen del contenido: `--pre-header-height`
+     * desde 900px, `--pre-header-height-mobile` por debajo (opcional; si falta,
+     * mobile usa `--pre-header-height`). Default `0px`, asi que sin el slot el
+     * layout queda byte-identico.
      */
     preHeader?: ReactNode;
     prerender_classes?: {
@@ -2270,19 +2273,23 @@ export declare type LibraryConfig = {
     /**
      * [banners] Nomenclatura de keys de banners. **Solo gatea los renombres que
      * REUSAN un nombre existente**; el resto de la nomenclatura nueva
-     * (`post_header`, `pre_footer`, `pre_header`, `destacado_N`,
+     * (`post_header`, `pre_footer`, `pre_header`,
      * `destacado_middle`, `block_N_middle`, `body_N`) no pasa por acá: son
      * nombres nuevos, sin colisión posible, y se resuelven siempre con fallback
      * canónico → legacy vía `findBanner`.
      *
      * - `'legacy'` (**default**) — comportamiento histórico, byte-idéntico.
      *   Los middles dinámicos del home siguen siendo `middle_dynamic_<slot>` y
-     *   los middles de nota siguen numerados desde `middle_2`.
+     *   los middles de nota siguen numerados desde `middle_2`. El banner
+     *   interno del destacado es `destacado_1` con `rightOnlyBanner` y
+     *   `destacado_2` sin él.
      * - `'v2'` — los middles dinámicos del home pasan a `middle_<slot>` (con
      *   fallback a `middle_dynamic_<slot>`) y la nota renumera sus middles
-     *   arrancando en `middle_1`.
+     *   arrancando en `middle_1`. El banner interno del destacado es siempre
+     *   `destacado_1` (`rightOnlyBanner` ya no cambia el índice) y
+     *   `destacado_2` queda para el banner externo, que renderiza el sitio.
      *
-     * POR QUÉ ES UN FLAG Y NO UN FALLBACK MÁS. Estos dos casos no son un
+     * POR QUÉ ES UN FLAG Y NO UN FALLBACK MÁS. Estos casos no son un
      * renombre, son un SWAP: `middle_N` sigue existiendo después del cambio pero
      * apunta a otra posición física. Con fallback gradual, un sitio a medio
      * migrar resolvería el `middle_1` viejo (estático, arriba) desde la posición