Installer SuperScheduler Pro

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 (↗) : 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.
• 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 :

{
  "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 :

npm install

Lancer npm install avec l’URL en argument revient au même et écrit l’entrée à votre place :

npm install https://npm.superscheduler.org/pro/YOUR_DOWNLOAD_KEY/0.1.0.tgz

Vérifiez le résultat :

npm ls super-scheduler react react-dom

Vous devriez voir [email protected] 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 :

{
  "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 (↗).

#npm install ou npm ci

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 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.

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.

#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 (↗) 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 :

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(
  <StrictMode>
    <Planning />
  </StrictMode>,
)

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<SuperScheduler.EventData[]>([
    {
      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 (
    <SuperSchedulerComponent
      startDate="2026-10-01"
      days={31}
      scale="Day"
      cellWidth={44}
      timeHeaders={TIME_HEADERS}
      resources={ROOMS}
      events={owned}
      onEventsChange={onEventsChange}
    />
  )
}

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.

Les fonctionnalités facultatives ont leurs propres sous-chemins : vous ne chargez que ce que vous importez.

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

Pour les problèmes à l’exécution après l’installation, voir Dépannage.

#Étapes suivantes

• Découvrez comment le composant s’insère dans une application React : Intégration React.
• Branchez vos données et votre backend : Événements contrôlés et callbacks.
• Ajoutez des règles métier au glisser : Glisser, redimensionner et règles métier.