Runnable starters showing forceCalendar inside the enterprise platforms most calendar libraries can't enter — sandboxed runtimes with strict CSP, no eval, no dynamic code, and dependency audits.
forceCalendar was built for the most hostile of them all (Salesforce Lightning Locker Service — see the first-class salesforce distribution). The same constraints make it run everywhere below.
| Example | Platform | What it shows |
|---|---|---|
cloudflare-worker-scheduling |
Cloudflare Workers | @forcecalendar/core as a server-side scheduling engine at the edge: RRULE expansion, conflict detection, ICS export — in a runtime that bans eval |
chrome-extension-mv3 |
Chrome Extensions (Manifest V3) | The <forcecal-main> Web Component under MV3's strict CSP: no remote code, no eval, everything bundled |
sharepoint-spfx-webpart |
SharePoint / Microsoft Teams (SPFx) | A calendar web part for Microsoft 365 pages and Teams tabs |
servicenow-portal-widget |
ServiceNow Service Portal | A scheduling widget over ServiceNow table data |
atlassian-forge-app |
Atlassian Forge (Jira) | A sprint calendar as a Forge Custom UI app inside Forge's CSP'd iframe |
Each example pins the published npm packages (@forcecalendar/core, @forcecalendar/interface) and includes a README that gets you running in minutes.
These are intentionally minimal starters, not supported products. When an example accumulates real-world traction — issues, questions, adoption from that ecosystem — it graduates into a first-class packaged distribution with its own repo, release pipeline, and support, exactly like salesforce did. Showing up here with issues and PRs is how you vote.
Org-wide contributing guide · security policy