# Instalar SuperScheduler Pro > Instala Pro con npm desde su tarball HTTPS privado y versionado, mantén íntegro el lockfile, actualiza con cuidado, úsalo en CI y protege la clave de descarga. Source: https://superscheduler.org/es/docs/install-pro/ Reviewed: 2026-10-07 Añade "super-scheduler": "https://npm.superscheduler.org/pro/YOUR_DOWNLOAD_KEY/0.1.0.tgz" a tus dependencias y ejecuta npm install una vez: npm descarga el archivo y registra su integridad SHA-512 en package-lock.json. A partir de ahí, npm ci instala exactamente ese archivo, en local y en CI. Los imports siguen siendo super-scheduler y super-scheduler/styles.css, React 18.2+ o 19 es una peer dependency y la clave de la URL es un secreto de descarga. SuperScheduler Pro no está en el registro público de npm. Cada versión es un archivo versionado (`.tgz`) servido por HTTPS, y tu clave de descarga personal forma parte de su URL. npm lo admite de forma nativa como [dependencia por URL](https://docs.npmjs.com/cli/v11/configuring-npm/package-json/#urls-as-dependencies): sin configurar un registro, sin cambios en `.npmrc` y sin inicio de sesión interactivo. Una vez instalado, el paquete se llama `super-scheduler` y se comporta como cualquier otra dependencia. Esta guía usa npm. Sustituye `YOUR_DOWNLOAD_KEY` por la clave que has recibido; los ejemplos fijan la versión `0.1.0`. ## Antes de empezar - **Una clave de descarga.** Solo autoriza descargas. Consulta [Mantener en secreto la clave de descarga](#download-key). - **React 18.2 o posterior, o React 19**, con el `react-dom` correspondiente. Ambos son peer dependencies; la librería no tiene dependencias propias en tiempo de ejecución. - **Acceso HTTPS** a `npm.superscheduler.org` desde cada máquina que instale dependencias (portátiles de desarrollo, runners de CI, contenedores de build). ## Añadir la dependencia Añade la URL del tarball a `dependencies` en `package.json`: ```json { "dependencies": { "super-scheduler": "https://npm.superscheduler.org/pro/YOUR_DOWNLOAD_KEY/0.1.0.tgz", "react": "^19.0.0", "react-dom": "^19.0.0" } } ``` Después, instala: ```sh npm install ``` Ejecutar `npm install` con la URL como argumento hace lo mismo y escribe la entrada por ti: ```sh npm install https://npm.superscheduler.org/pro/YOUR_DOWNLOAD_KEY/0.1.0.tgz ``` Comprueba el resultado: ```sh npm ls super-scheduler react react-dom ``` Deberías ver `super-scheduler@0.1.0` y una única versión de `react` y de `react-dom`. ## Qué registra el lockfile La primera instalación descarga el archivo, calcula su hash SHA-512 y guarda tanto la URL como el hash en `package-lock.json`: ```json { "packages": { "node_modules/super-scheduler": { "version": "0.1.0", "resolved": "https://npm.superscheduler.org/pro/YOUR_DOWNLOAD_KEY/0.1.0.tgz", "integrity": "sha512-…", "peerDependencies": { "react": "^18.2.0 || ^19.0.0", "react-dom": "^18.2.0 || ^19.0.0" } } } } ``` El valor de `integrity` es lo que hace reproducible la instalación. El archivo de una versión publicada nunca cambia, así que cada instalación posterior de `0.1.0`, en cualquier máquina, debe producir el mismo hash; si los bytes descargados fueran distintos alguna vez, npm se detendría con un error `EINTEGRITY` en lugar de instalarlos. Haz commit de `package-lock.json` junto con `package.json` y no edites nunca a mano el campo `integrity`. La documentación de npm describe los [campos `resolved` e `integrity`](https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json/#packages). ## npm install o npm ci | Comando | Cuándo usarlo | Qué hace con Pro | |---|---|---| | `npm install` | Cuando añades o actualizas una dependencia, o cambias su URL | Resuelve la URL, descarga el archivo y reescribe `resolved` e `integrity` en el lockfile cuando cambian | | `npm ci` | En todos los demás casos: clones nuevos, CI, builds de Docker, despliegues | Borra `node_modules` e instala exactamente lo que dice el lockfile, verificando la integridad; falla si `package.json` y el lockfile no coinciden | En la automatización, usa preferentemente `npm ci`. Nunca reescribe el lockfile, así que un build no puede coger otro archivo sin que te enteres. ## Actualizar a una nueva versión La URL de un tarball es una dirección fija, no un rango semver: `npm update` y `npm outdated` no ven las nuevas versiones de Pro y nada se actualiza solo. Para pasar a una nueva versión: 1. Lee el [registro de cambios](https://superscheduler.org/es/changelog/) de la versión de destino. 2. Cambia la versión al final de la URL, por ejemplo de `…/YOUR_DOWNLOAD_KEY/0.1.0.tgz` al número de la nueva versión. 3. Ejecuta `npm install` para descargar el nuevo archivo y regenerar su entrada en el lockfile. 4. Ejecuta la comprobación de tipos y los tests, y haz commit de `package.json` y `package-lock.json` juntos. Para volver atrás, apunta la URL a la versión anterior y vuelve a ejecutar `npm install`. Los archivos publicados son inmutables, así que la versión anterior se instala con la misma integridad que tenía. ## Integración continua CI no necesita nada más de lo que ya hace con los paquetes públicos: la URL y la integridad están en el lockfile y la descarga no requiere iniciar sesión. ```sh npm ci npm run typecheck npm test npm run build ``` Ten en cuenta por dónde viaja la clave de descarga en CI: - **Cachés de dependencias.** Si cacheas el directorio de caché de npm o `node_modules` entre ejecuciones, el archivo cacheado y el lockfile son tan sensibles como la propia clave. Mantén las cachés privadas al proyecto. - **Logs.** Los mensajes de error de npm pueden incluir la URL que intentó descargar, con la clave. No publiques los logs de CI de proyectos privados. - **Forks y mirrors públicos.** Un repositorio que contiene la clave debe seguir siendo privado. No lo subas a un mirror público. ## Mantener en secreto la clave de descarga La clave es un secreto al portador para las descargas. Cualquiera que tenga la URL puede descargar esa versión, así que merece el mismo cuidado que un token de API: - Aparece en `package.json`, en `package-lock.json`, en la caché local de npm y posiblemente en los logs. Mantén privados el repositorio y esos archivos. - No pegues la URL en issues públicas, chats, gists, capturas de pantalla ni informes de errores. Cuando compartas una lista de dependencias, sustituye la clave por `YOUR_DOWNLOAD_KEY`. - Si la clave queda expuesta, pide una nueva, sustitúyela en `package.json`, ejecuta `npm install` y haz commit de los dos archivos. El archivo descargado es el mismo, así que solo cambia la URL de `resolved`; la integridad sigue siendo idéntica. > **Limitation:** > La clave controla las descargas y nada más. Revocarla bloquea nuevas descargas desde el servidor, pero no elimina los archivos ya descargados, las cachés de npm ni el código ya empaquetado en una aplicación. No es una comprobación de licencia en tiempo de ejecución ni un DRM: el paquete instalado no contacta con ningún servidor. ## Peer dependencies y un único React Pro declara `react` y `react-dom` `^18.2.0 || ^19.0.0` como peer dependencies y usa la copia de tu aplicación. npm informa de un conflicto de peer dependencies si tu proyecto usa un React más antiguo. En el bundle debe haber exactamente un React. Dos copias rompen los hooks y el contexto, de los que dependen `useSchedulerControl`, el subpath `super-scheduler/hooks` y los slots de renderizado de `super-scheduler/react-render`. `npm ls react react-dom` debe mostrar una única versión. En un monorepo, o cuando enlazas paquetes en local, indica al bundler que resuelva una sola copia, por ejemplo con [`resolve.dedupe`](https://vite.dev/config/shared-options.html#resolve-dedupe) de Vite con el valor `['react', 'react-dom']`. ## Imports y estilos El paquete se llama `super-scheduler`, sea cual sea la URL desde la que se instaló. Importa la hoja de estilos una sola vez, en tu archivo de entrada, antes de tu propio CSS: ```tsx // src/main.tsx import { StrictMode } from 'react' import { createRoot } from 'react-dom/client' import { version } from 'super-scheduler' // Once per application, before your own stylesheets. The library rules live in // `@layer super-scheduler`, so any unlayered rule of yours wins without !important. import 'super-scheduler/styles.css' import './app.css' import { Planning } from './Planning' // '0.1.0': the version your bundler resolved from the tarball. console.info(`SuperScheduler ${version}`) const container = document.getElementById('root') if (container === null) throw new Error('#root is missing') createRoot(container).render( , ) ``` ```tsx // src/Planning.tsx import { useMemo, useState } from 'react' import { SuperSchedulerComponent } from 'super-scheduler' import type { SchedulerEventsChangeArgs, SuperScheduler } from 'super-scheduler' const ROOMS: SuperScheduler.ResourceData[] = [ { id: 'r101', name: 'Room 101' }, { id: 'r102', name: 'Room 102' }, ] const TIME_HEADERS: SuperScheduler.TimeHeaderData[] = [ { groupBy: 'Month' }, { groupBy: 'Day', format: 'd' }, ] export function Planning() { const [events, setEvents] = useState([ { id: 1, resource: 'r101', start: '2026-10-02T14:00:00', end: '2026-10-05T11:00:00', text: 'Booking 1042', }, ]) // The control edits the array it receives in place: hand it a copy of the state. const owned = useMemo(() => events.slice(), [events]) const onEventsChange = (args: SchedulerEventsChangeArgs) => setEvents([...args.events]) return ( ) } ``` Deberías ver un mes de columnas de día, dos habitaciones y una reserva. Arrastra la reserva a la otra habitación: `onEventsChange` escribe su nueva posición en el estado de React, que es el patrón descrito en [Eventos controlados y callbacks](https://superscheduler.org/es/docs/controlled-state/). Las funcionalidades opcionales viven en sus propios subpaths, así que solo cargas lo que importas: | Import | Contenido | |---|---| | `super-scheduler` | `SuperSchedulerComponent`, el namespace `SuperScheduler`, `useSchedulerControl`, todos los tipos públicos, `version` | | `super-scheduler/styles.css` | La hoja de estilos y sus tokens `--super-scheduler-*` | | `super-scheduler/react-render` | Una variante del componente con slots de renderizado React y tarjetas emergentes | | `super-scheduler/history` | Deshacer y rehacer | | `super-scheduler/minimap` | Vista general de la línea de tiempo con un selector de la zona visible | | `super-scheduler/panes` | Varios paneles del scheduler coordinados, con separadores | | `super-scheduler/zoom-ui` | Control deslizante de zoom, indicador de zoom y distintivo de nivel de detalle | | `super-scheduler/views` | Guarda y restaura el zoom, la posición de scroll, la densidad, las filas plegadas y las columnas | | `super-scheduler/ranges` | Carga cancelable de eventos por rango de fechas | | `super-scheduler/hooks` | Suscripciones de React al estado del scheduler | | `super-scheduler/core` | Utilidades de fechas, duraciones y línea de tiempo sin DOM | | `super-scheduler/datasets` | Datos de ejemplo deterministas para demos y tests | | `super-scheduler/tailwind` | Preset para Tailwind CSS v3 | Cada entrada incluye módulos ES y CommonJS con declaraciones de TypeScript para ambos. `moduleResolution: "bundler"`, `"node16"` y `"nodenext"` leen los `exports` del paquete; la resolución `"node"`, más antigua, también encuentra los tipos de los subpaths. Algunas funcionalidades y paquetes de idioma se cargan bajo demanda con `import()` dinámico, así que mantén activado el code splitting de tu bundler (viene activado por defecto en Vite, Next.js y webpack). ## Resolver problemas de instalación | Síntoma | Causa y solución | |---|---| | npm falla con HTTP 403 en la URL del tarball | La clave es incorrecta, ha caducado o se ha revocado. Busca errores al copiarla; pide una clave nueva si hace falta | | npm falla con HTTP 404 | La clave es válida, pero esa versión no existe. Compara la versión de la URL con el [registro de cambios](https://superscheduler.org/es/changelog/) | | `EINTEGRITY` | Los bytes descargados no coinciden con el hash del lockfile. Los archivos publicados nunca cambian, así que busca una caché dañada (`npm cache verify`) o un lockfile editado o fusionado a mano (restáuralo desde el control de versiones). No sustituyas nunca el hash para que desaparezca el error | | `npm ci` dice que el lockfile no está sincronizado | `package.json` cambió sin ejecutar `npm install`. Ejecuta `npm install` y haz commit de los dos archivos | | `ERESOLVE` mencionando React | Tu React es anterior a 18.2. Actualiza React primero | | «Invalid hook call» desde los hooks de SuperScheduler | Hay dos copias de React. Consulta [un único React](#react) | | La cuadrícula no tiene bordes ni colores | No se ha importado `super-scheduler/styles.css` | Para problemas en tiempo de ejecución después de la instalación, consulta [Solución de problemas](https://superscheduler.org/es/docs/troubleshooting/). ## Siguientes pasos - Aprende cómo encaja el componente en una aplicación React: [Integración con React](https://superscheduler.org/es/docs/react-integration/). - Conecta tus datos y tu backend: [Eventos controlados y callbacks](https://superscheduler.org/es/docs/controlled-state/). - Añade reglas de negocio al arrastre: [Arrastrar, redimensionar y reglas de negocio](https://superscheduler.org/es/docs/drag-resize-rules/).