# Installer SuperScheduler Pro > Installez Pro depuis son archive HTTPS privée et versionnée avec npm, préservez l’intégrité du lockfile, mettez à jour, utilisez-le en CI et protégez la clé. Source: https://superscheduler.org/fr/docs/install-pro/ Reviewed: 2026-10-07 Ajoutez "super-scheduler": "https://npm.superscheduler.org/pro/YOUR_DOWNLOAD_KEY/0.1.0.tgz" à vos dependencies et lancez npm install une fois : npm télécharge l’archive et enregistre son intégrité SHA-512 dans package-lock.json. Dès lors, npm ci installe exactement cette archive, en local comme en CI. Les imports restent super-scheduler et super-scheduler/styles.css, React 18.2+ ou 19 est une dépendance pair, et la clé contenue dans l’URL est un secret de téléchargement. SuperScheduler Pro n’est pas publié sur le registre npm public. Chaque version est une archive versionnée (`.tgz`) servie en HTTPS, et votre clé de téléchargement personnelle fait partie de son URL. npm prend en charge ce cas nativement sous la forme d’une [dépendance par URL](https://docs.npmjs.com/cli/v11/configuring-npm/package-json/#urls-as-dependencies) : aucune configuration de registre, aucune modification de `.npmrc` et aucune connexion interactive. Une fois installé, le paquet s’appelle `super-scheduler` et se comporte comme n’importe quelle autre dépendance. Ce guide utilise npm. Remplacez `YOUR_DOWNLOAD_KEY` par la clé que vous avez reçue ; les exemples figent la version `0.1.0`. ## Avant de commencer - **Une clé de téléchargement.** Elle autorise uniquement les téléchargements. Voir [Garder la clé de téléchargement secrète](#download-key). - **React 18.2 ou ultérieur, ou React 19**, avec la version de `react-dom` correspondante. Ce sont deux dépendances pair ; la bibliothèque n’a elle-même aucune dépendance à l’exécution. - **Un accès HTTPS** à `npm.superscheduler.org` depuis chaque machine qui installe les dépendances (postes des développeurs, runners de CI, conteneurs de build). ## Ajouter la dépendance Ajoutez l’URL de l’archive tarball aux `dependencies` de `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" } } ``` Puis installez : ```sh npm install ``` Lancer `npm install` avec l’URL en argument revient au même et écrit l’entrée à votre place : ```sh npm install https://npm.superscheduler.org/pro/YOUR_DOWNLOAD_KEY/0.1.0.tgz ``` Vérifiez le résultat : ```sh npm ls super-scheduler react react-dom ``` Vous devriez voir `super-scheduler@0.1.0` et une seule version de `react` et de `react-dom`. ## Ce qu’enregistre le lockfile La première installation télécharge l’archive, calcule son empreinte SHA-512 et enregistre l’URL et l’empreinte dans `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" } } } } ``` C’est la valeur `integrity` qui rend l’installation reproductible. L’archive d’une version publiée ne change jamais : toute installation ultérieure de `0.1.0`, sur n’importe quelle machine, doit donc produire la même empreinte ; si les octets téléchargés différaient un jour, npm s’arrêterait sur une erreur `EINTEGRITY` au lieu de les installer. Committez `package-lock.json` avec `package.json`, et ne modifiez jamais le champ `integrity` à la main. La documentation de npm décrit les [champs `resolved` et `integrity`](https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json/#packages). ## npm install ou npm ci | Commande | Quand l’utiliser | Ce qu’elle fait avec Pro | |---|---|---| | `npm install` | Vous ajoutez une dépendance, la mettez à jour ou changez son URL | Résout l’URL, télécharge l’archive et réécrit `resolved` et `integrity` dans le lockfile s’ils changent | | `npm ci` | Partout ailleurs : clones neufs, CI, builds Docker, déploiements | Supprime `node_modules` et installe exactement ce qu’indique le lockfile, en vérifiant l’intégrité ; échoue si `package.json` et le lockfile ne concordent pas | Préférez `npm ci` dans l’automatisation. Cette commande ne réécrit jamais le lockfile : un build ne peut donc pas récupérer en silence une autre archive. ## Passer à une nouvelle version Une URL d’archive tarball est une adresse fixe, pas une plage semver : `npm update` et `npm outdated` ne voient pas les nouvelles versions de Pro, et rien ne se met à jour tout seul. Pour passer à une nouvelle version : 1. Lisez le [journal des modifications](https://superscheduler.org/fr/changelog/) de la version cible. 2. Modifiez la version à la fin de l’URL, par exemple en remplaçant `…/YOUR_DOWNLOAD_KEY/0.1.0.tgz` par le nouveau numéro de version. 3. Lancez `npm install` pour télécharger la nouvelle archive et régénérer son entrée dans le lockfile. 4. Lancez votre vérification de types et vos tests, puis committez `package.json` et `package-lock.json` ensemble. Pour revenir en arrière, faites pointer l’URL vers la version précédente et relancez `npm install`. Les archives publiées sont immuables : la version précédente s’installe avec la même intégrité qu’auparavant. ## Intégration continue La CI n’a besoin de rien de plus que ce qu’elle fait déjà pour les paquets publics : l’URL et l’intégrité sont dans le lockfile, et le téléchargement ne demande aucune connexion. ```sh npm ci npm run typecheck npm test npm run build ``` Gardez en tête les endroits où transite la clé de téléchargement en CI : - **Caches de dépendances.** Si vous mettez en cache le répertoire de cache de npm ou `node_modules` entre deux exécutions, l’archive en cache et le lockfile sont aussi sensibles que la clé elle-même. Gardez ces caches privés au projet. - **Logs.** Les messages d’erreur de npm peuvent contenir l’URL tentée, clé comprise. Ne publiez pas les logs de CI de projets privés. - **Forks et miroirs publics.** Un dépôt qui contient la clé doit rester privé. Ne le poussez pas vers un miroir public. ## Garder la clé de téléchargement secrète La clé est un secret porteur (bearer) pour les téléchargements. Quiconque possède l’URL peut télécharger cette version : elle mérite donc le même soin qu’un jeton d’API. - Elle apparaît dans `package.json`, dans `package-lock.json`, dans le cache local de npm et parfois dans les logs. Gardez le dépôt et ces fichiers privés. - Ne collez pas l’URL dans des issues publiques, des messageries, des gists, des captures d’écran ou des rapports de bug. Quand vous partagez une liste de dépendances, remplacez la clé par `YOUR_DOWNLOAD_KEY`. - Si la clé est exposée, demandez-en une nouvelle, remplacez-la dans `package.json`, lancez `npm install` et committez les deux fichiers. L’archive est la même : seule l’URL `resolved` change ; l’intégrité reste identique. > **Limitation:** > La clé contrôle les téléchargements, et rien d’autre. La révoquer bloque les nouveaux téléchargements depuis le serveur, mais ne supprime ni les archives déjà téléchargées, ni les caches npm, ni le code déjà intégré au bundle d’une application. Ce n’est ni une vérification de licence à l’exécution ni un DRM : le paquet installé ne contacte aucun serveur. ## Dépendances pair et un seul React Pro déclare `react` et `react-dom` `^18.2.0 || ^19.0.0` comme dépendances pair et utilise la copie de votre application. npm signale un conflit de dépendances pair si votre projet utilise une version plus ancienne de React. Le bundle doit contenir exactement un React. Deux copies cassent les hooks et le contexte, sur lesquels reposent `useSchedulerControl`, le sous-chemin `super-scheduler/hooks` et les slots de rendu de `super-scheduler/react-render`. `npm ls react react-dom` doit afficher une seule version. Dans un monorepo, ou quand vous liez des paquets en local, demandez au bundler de résoudre une seule copie, par exemple avec l’option [`resolve.dedupe`](https://vite.dev/config/shared-options.html#resolve-dedupe) de Vite réglée sur `['react', 'react-dom']`. ## Imports et styles Le nom du paquet est `super-scheduler`, quelle que soit l’URL depuis laquelle il a été installé. Importez la feuille de style une seule fois, dans votre fichier d’entrée, avant votre propre 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 ( ) } ``` Vous devriez voir un mois de colonnes de jours, deux chambres et une réservation. Faites glisser la réservation vers l’autre chambre : `onEventsChange` écrit sa nouvelle position dans le state React, selon le modèle décrit dans [Événements contrôlés et callbacks](https://superscheduler.org/fr/docs/controlled-state/). Les fonctionnalités facultatives ont leurs propres sous-chemins : vous ne chargez que ce que vous importez. | Import | Contenu | |---|---| | `super-scheduler` | `SuperSchedulerComponent`, l’espace de noms `SuperScheduler`, `useSchedulerControl`, tous les types publics, `version` | | `super-scheduler/styles.css` | La feuille de style et ses tokens `--super-scheduler-*` | | `super-scheduler/react-render` | Une variante du composant avec slots de rendu React et cartes de survol | | `super-scheduler/history` | Annuler et rétablir | | `super-scheduler/minimap` | Vue d’ensemble de la frise avec une fenêtre de sélection déplaçable | | `super-scheduler/panes` | Plusieurs volets de planificateur coordonnés, avec séparateurs | | `super-scheduler/zoom-ui` | Curseur de zoom, indicateur de zoom et badge de niveau de détail | | `super-scheduler/views` | Enregistrement et restauration du zoom, de la position de défilement, de la densité, des lignes repliées et des colonnes | | `super-scheduler/ranges` | Chargement annulable des événements par plage de dates | | `super-scheduler/hooks` | Abonnements React à l’état du planificateur | | `super-scheduler/core` | Utilitaires de dates, de durées et de frise, sans DOM | | `super-scheduler/datasets` | Données d’exemple déterministes pour les démos et les tests | | `super-scheduler/tailwind` | Preset pour Tailwind CSS v3 | Chaque point d’entrée est fourni en modules ES et en CommonJS, avec des déclarations TypeScript pour les deux. `moduleResolution: "bundler"`, `"node16"` et `"nodenext"` lisent les `exports` du paquet ; l’ancienne résolution `"node"` trouve aussi les types des sous-chemins. Certaines fonctionnalités et certains packs de langue sont chargés à la demande avec un `import()` dynamique : laissez donc le découpage de code (code splitting) de votre bundler activé (il l’est par défaut dans Vite, Next.js et webpack). ## Dépannage de l’installation | Symptôme | Cause et solution | |---|---| | npm échoue avec une erreur HTTP 403 sur l’URL de l’archive | La clé est erronée, expirée ou révoquée. Vérifiez les erreurs de copie ; demandez une nouvelle clé si nécessaire | | npm échoue avec une erreur HTTP 404 | La clé est valide mais cette version n’existe pas. Comparez la version de l’URL avec le [journal des modifications](https://superscheduler.org/fr/changelog/) | | `EINTEGRITY` | Les octets téléchargés ne correspondent pas à l’empreinte du lockfile. Les archives publiées ne changent jamais : cherchez un cache endommagé (`npm cache verify`) ou un lockfile modifié ou fusionné à la main (restaurez-le depuis le contrôle de version). Ne remplacez jamais l’empreinte pour faire disparaître l’erreur | | `npm ci` indique que le lockfile n’est pas synchronisé | `package.json` a changé sans `npm install`. Lancez `npm install` et committez les deux fichiers | | `ERESOLVE` mentionnant React | Votre React est antérieur à 18.2. Mettez d’abord React à jour | | « Invalid hook call » depuis les hooks de SuperScheduler | Deux copies de React. Voir [un seul React](#react) | | La grille n’a ni bordures ni couleurs | `super-scheduler/styles.css` n’est pas importé | Pour les problèmes à l’exécution après l’installation, voir [Dépannage](https://superscheduler.org/fr/docs/troubleshooting/). ## Étapes suivantes - Découvrez comment le composant s’insère dans une application React : [Intégration React](https://superscheduler.org/fr/docs/react-integration/). - Branchez vos données et votre backend : [Événements contrôlés et callbacks](https://superscheduler.org/fr/docs/controlled-state/). - Ajoutez des règles métier au glisser : [Glisser, redimensionner et règles métier](https://superscheduler.org/fr/docs/drag-resize-rules/).