forceCalendar was built for the most restrictive runtime in enterprise software: Salesforce Lightning Locker Service. The same engineering (zero dependencies, no eval, no dynamic code, no inline-style injection) makes it run inside every sandboxed platform below.
Each links to an installable distribution or a runnable starter.
Locker Service / LWS: no eval, no dynamic code, no prototype manipulation
The founding use case. A first-class packaged distribution: LWC component, Apex controller over the Event sObject, one-command deploy.
Install guideEdge runtime: eval and code generation banned outright
The headless core as a server-side scheduling engine at the edge: RRULE expansion, conflict detection, and ICS export with zero dependencies to cold-start.
Runnable exampleManifest V3 CSP: no remote code, no eval, everything bundled
The Web Component in an extension popup with no build step at all: an import map plus vendored packages is enough.
Runnable exampleSecurity-reviewed, size-audited bundles
A calendar web part for Microsoft 365 pages and Teams tabs. Zero transitive dependencies means nothing extra for your review board to audit.
StarterSandboxed widget scripting
A Service Portal widget over ServiceNow table data: scheduling and dispatch calendars without fighting the platform sandbox.
StarterCustom UI in a strictly CSP'd iframe, Marketplace dependency scrutiny
A sprint calendar as a Forge Custom UI project page, with the packages vendored into static assets.
StarterThese starters are intentionally minimal. When one attracts real-world traction, it graduates into a first-class packaged distribution with its own repo and release pipeline, exactly like Salesforce did. Open issues on the examples repo to vote with your use case.