Install SuperScheduler Pro

SuperScheduler Pro is not on the public npm registry. Each release is a versioned archive (.tgz) served over HTTPS, and your personal download key is part of its URL. npm supports this natively as a URL dependency (↗): no registry configuration, no .npmrc changes and no interactive login. Once installed, the package is named super-scheduler and behaves like any other dependency.

This guide uses npm. Replace YOUR_DOWNLOAD_KEY with the key you received; the examples pin version 0.1.0.

#Before you start

• A download key. It authorizes downloads only. See Keep the download key secret.
• React 18.2 or later, or React 19, with the matching react-dom. Both are peer dependencies; the library has no runtime dependencies of its own.
• HTTPS access from every machine that installs dependencies (developer laptops, CI runners, build containers) to npm.superscheduler.org.

#Add the dependency

Add the tarball URL to dependencies in 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"
  }
}

Then install:

npm install

Running npm install with the URL as an argument does the same and writes the entry for you:

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

Check the result:

npm ls super-scheduler react react-dom

You should see [email protected] and a single version of react and react-dom.

#What the lockfile records

The first install downloads the archive, computes its SHA-512 hash and stores both the URL and the hash in 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"
      }
    }
  }
}

The integrity value is what makes the install reproducible. The archive behind a released version never changes, so every later install of 0.1.0, on any machine, must produce the same hash; if the downloaded bytes ever differed, npm would stop with an EINTEGRITY error instead of installing them. Commit package-lock.json together with package.json, and never edit the integrity field by hand. The npm documentation describes the resolved and integrity fields (↗).

#npm install or npm ci

Prefer npm ci in automation. It never rewrites the lockfile, so a build cannot silently pick up a different archive.

#Upgrade to a new version

A tarball URL is a fixed address, not a semver range: npm update and npm outdated do not see new Pro releases, and nothing upgrades by itself. To move to a new version:

1. Read the changelog for the target version.
2. Change the version at the end of the URL, for example …/YOUR_DOWNLOAD_KEY/0.1.0.tgz to the new version number.
3. Run npm install to download the new archive and regenerate its lockfile entry.
4. Run your type check and tests, then commit package.json and package-lock.json together.

To roll back, point the URL at the previous version and run npm install again. Released archives are immutable, so the previous version installs with the same integrity it had before.

#Continuous integration

CI needs nothing beyond what it already does for public packages: the URL and the integrity are in the lockfile, and the download requires no login.

npm ci
npm run typecheck
npm test
npm run build

Keep in mind where the download key travels in CI:

• Dependency caches. If you cache npm's cache directory or node_modules between runs, the cached archive and the lockfile are as sensitive as the key itself. Keep caches private to the project.
• Logs. npm error messages can include the URL it tried, key included. Do not publish CI logs of private projects.
• Forks and public mirrors. A repository that contains the key must stay private. Do not push it to a public mirror.

#Keep the download key secret

The key is a bearer secret for downloads. Anyone who has the URL can download that release, so it deserves the same care as an API token:

• It appears in package.json, package-lock.json, npm's local cache and possibly in logs. Keep the repository and those files private.
• Do not paste the URL into public issues, chats, gists, screenshots or bug reports. When you share a dependency list, replace the key with YOUR_DOWNLOAD_KEY.
• If the key is exposed, ask for a new one, replace it in package.json, run npm install and commit both files. The archive is the same, so only the resolved URL changes; the integrity stays identical.

#Peer dependencies and a single React

Pro declares react and react-dom ^18.2.0 || ^19.0.0 as peer dependencies and uses your application's copy. npm reports a peer dependency conflict if your project is on an older React.

There must be exactly one React in the bundle. Two copies break hooks and context, which useSchedulerControl, the super-scheduler/hooks subpath and the render slots of super-scheduler/react-render rely on. npm ls react react-dom must show a single version. In a monorepo or when you link packages locally, tell the bundler to resolve one copy, for example with Vite's resolve.dedupe (↗) set to ['react', 'react-dom'].

#Imports and styles

The package name is super-scheduler, whatever URL it was installed from. Import the stylesheet once, in your entry file, before your own 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}
    />
  )
}

You should see a month of day columns, two rooms and one booking. Drag the booking to the other room: onEventsChange writes its new position into React state, which is the pattern described in Controlled events and callbacks.

Optional features live in their own subpaths, so you only load what you import:

Every entry ships ES modules and CommonJS with TypeScript declarations for both. moduleResolution: "bundler", "node16" and "nodenext" read the package's exports; older "node" resolution finds the subpath types too. Some features and language packs are loaded on demand with dynamic import(), so keep your bundler's code splitting enabled (it is on by default in Vite, Next.js and webpack).

#Troubleshooting the installation

For runtime problems after installation, see Troubleshooting.

#Next steps

• Learn how the component fits a React app: React integration.
• Wire your data and backend: Controlled events and callbacks.
• Add business rules to dragging: Drag, resize and business rules.