Schedule-X: one Preact calendar engine wrapped for five frameworks

Two runtime dependencies explain the whole architecture

The GitHub description names the comparison outright: a JavaScript event calendar positioned as a modern alternative to fullcalendar and react-big-calendar. What separates it structurally is visible in the workspace root, where the entire runtime dependency list is two entries.

"dependencies": {
  "@preact/signals": "^2.0.2",
  "preact": "10.26.4"
}

Those two packages say more than any architecture diagram would. Preact renders the calendar itself, and `@preact/signals` carries the state that changes as you page between months, open an event view, or toggle a calendar's visibility. Signals give fine grained updates without re-running the whole tree, which is what lets a month grid repaint without dragging every surrounding component through reconciliation.

The five framework links in the README, React, Angular, Vue, Svelte and Preact, are wrappers over that one core rather than five separate implementations. A single engine also means a single set of behaviour, so a date renders the same way whichever integration you mount it in.

Where the README stops and schedule-x.dev takes over

What the README does not contain matters as much as what it does. There is no install command, no calendar creation snippet, no list of configuration options and no API reference. The file is short: a logo, four badges, one paragraph of positioning, a demo animation, and pointers to schedule-x.dev. The npm badge tracks monthly downloads for `@schedule-x/calendar`, which names the primary package even though no code sample in the repository ever shows it.

Everything a developer actually needs, view configuration, event objects, localization, plugin registration, is on the documentation site. The repository carries both a `documentation/` directory and a `website/` directory to support that.

The practical consequence is worth stating plainly. Reading the README tells you which problem the author thinks Schedule-X solves and which frameworks matter. It does not tell you whether a specific requirement, recurring events, resource columns, drag boundaries between calendars, is supported. Those answers live on the website, and they can change without a corresponding note appearing in this repository.

Running the suite under three timezones from docker-compose

Timezone handling is where calendar libraries earn or lose trust, and this repository treats it as build infrastructure rather than an afterthought. The `docker-compose.yml` at the root defines three services that build the same `test-runner.dockerfile`, each pinned to a different local time.

test_london:
  build:
    context: .
    dockerfile: test-runner.dockerfile
  environment:
    TZ: "Europe/London"

The other two chain behind the first through `depends_on`. `test_mountain_view` sets `US/Pacific` and waits on `test_london`; `test_tokyo` sets `Asia/Tokyo` and waits on `test_mountain_view`. All three share a network named `test`.

The comment above the services is candid about the intent: they exist so the test logs appear in more orderly fashion. Reading the serialization as a correctness mechanism would overstate it. What the setup does mean is that the suite runs end to end under a UTC+9 zone and under a Pacific zone that shifts offset twice a year, so a date or daylight-saving bug is exercised by construction rather than by luck.

A private 0.0.0 root that publishes the packages beneath it

The root package.json reads more like a factory floor than an application. It is private, pinned at 0.0.0, and never reaches npm itself.

"version": "0.0.0",
"private": true,
"workspaces": [
  "packages/*",
  "libs/*",
  "websites/*"
]

The version a user installs lives in the individual packages under `packages/*`, and `lerna publish` walks them with conventional commits driving the bumps.

"release": "npm run build && lerna publish --conventional-commits --no-commit-hooks --force-publish --no-private",
"release:pre": "npm run build && lerna publish --no-commit-hooks --conventional-commits --conventional-prerelease --force-publish"

There are no GitHub releases in this repository at all. For a project with roughly 2,585 stars that is unusual, and it is not neglect: the release trail simply lives on npm, where `@schedule-x/calendar` and its siblings are consumed. Recent changes are a changelog lookup, not a releases page check.

Both `lerna.json` and `nx.json` sit in the tree beside `rollup.config.js`, so build orchestration is layered rather than singular. One inconsistency is worth naming. The workspaces array globs `websites/*`, but the directory in the repository is `website/`, singular. As written that glob matches nothing.

Topic tags advertise surface the README never mentions

Alongside calendar, javascript, react, angular, vue and svelte, the repository is tagged `date-picker` and `icalendar-events`. Neither a date picker nor iCalendar support appears anywhere in the README.

The sensible reading is that Schedule-X ships capability as scoped packages alongside the calendar itself, so the tags describe the project surface rather than the core. That matches the npm badge tracking `@schedule-x/calendar` alone: the calendar is what people find first, and a date picker or iCal integration is a separate install layered on top.

The gap runs the other direction as well. Preact is missing from the topic tags even though the README lists it first among supported frameworks and the workspace root depends on `preact` directly. Filter by topic and the Preact story vanishes; read the README and it is one of five first class integrations. Neither list is authoritative on its own, which is worth remembering before you conclude a feature does not exist.

How it stacks up against the two calendars it names

Against the projects its own description names, the honest summary is this. FullCalendar and React Big Calendar have larger plugin ecosystems and longer histories, and either is the safer default when a team needs a niche widget that already exists there. Schedule-X is younger and built on a single idea: one Preact and signals core with thin per-framework wrappers, so the calendar behaves identically no matter which stack renders it.

The repository backs that pitch with real tooling. Visual snapshots run through Cypress, recording baselines under a dedicated folder.

"test:e2e:record": "./node_modules/.bin/cypress run --env type=base --config screenshotsFolder=cypress/snapshots/mac/base",
"test:e2e:ci": "./node_modules/.bin/cypress run --env type=actual --config screenshotsFolder=cypress/snapshots/mac/actual"

Recording baselines in one timezone and comparing actuals in another is exactly the discipline a calendar needs, since a day boundary moving by one hour changes what appears in a cell. It is also the part of the pipeline most likely to be noisy on a contributor's machine, and the repo asks you to open an issue before sending a pull request, which keeps that discussion on the tracker instead of in a review thread.

The project is MIT licensed, copyright Tom Österlund dated 2023 to present, and funded through OpenCollective, which the README says covers compute and DNS costs. The last push to the default branch `main` was 2026-09-22, with 181 forks and 56 open issues at the time of writing.

Editorial conclusion

Schedule-X is a credible alternative to FullCalendar when you want one calendar behaviour across several frontend stacks, and the infrastructure backs that claim: a three-timezone test matrix, visual snapshot runs through Cypress, and conventional-commit publishing across a workspace of packages. The trade-off is that almost nothing you need is in the repository. Install commands, event models and plugin registration live on schedule-x.dev, so read that before you commit. The calendar package is the piece to install first; the rest of the family is opt-in.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. schedule-x/schedule-x on GitHub