Skip to content

BaseEventProperties

Base properties shared by all event types (ICS-compatible)

// Default usage
type Event = BaseEventProperties;
// With typed categories
type LiturgicalCategory = "solemnity" | "feast" | "memorial";
type LiturgicalEvent = BaseEventProperties<LiturgicalMetadata, LiturgicalCategory>;

TMetadata extends Record<string, unknown> = Record<string, unknown>

Custom metadata type extending Record<string, unknown>

TCategory extends string = string

Category type (default: string, can be enum for type safety)

optional allDay?: boolean


optional categories?: TCategory[]


optional color?: string


optional description?: string


optional duration?: number


optional endDate?: string


optional endTime?: string


optional exceptions?: EventExceptions

Per-occurrence exceptions keyed by the event’s ORIGINAL computed date (YYYY-MM-DD) — maps ICS EXDATE / RECURRENCE-ID. { skip: true } drops that occurrence; { override } replaces properties for that one instance.


optional icon?: string


id: string


optional keywords?: string[]


optional location?: string


optional metadata?: TMetadata


optional onConflict?: ConflictResolver

Conflict resolver for handling events on the same day. Called during event generation to determine action when this event would occur on a specific date.

Default behavior (when not specified): keep all events


optional overrideDates?: OverrideDatesMap

Force reschedule dates unconditionally. Unlike onConflict which handles conflicts, this always moves events. Key is the original computed date (YYYY-MM-DD), value is the new date.

overrideDates: {
"2026-02-18": "2026-02-20", // Move from Feb 18 to Feb 20
}

optional priority?: number

Display precedence when several events land on the same day, like CSS z-index: higher = on top, default 0. The core only sorts by this number (highest first); it assigns no meaning to the values — the consumer does. Ties keep generation order (stable).


optional reminders?: Reminder[]


optional source?: string

Origin of the event — the plugin, feed, or ICS subscription that produced it. Lets a consumer customize/filter in bulk by source (like toggling a calendar in Google/Apple Calendar) and namespaces the ICS export UID. Distinct from groupId (a user-defined group) and sourceEventId (the originating config id).


optional startDate?: string

Recurrence validity window (YYYY-MM-DD, both bounds inclusive). Occurrences before startDate or after endDate are dropped — applied centrally during generation, so it works for ANY event type (const, monthly, weekly, nth-weekday, plugin types…), not just the few that ship their own range fields.

Maps iCalendar semantics: startDateDTSTART lower bound, endDateRRULE;UNTIL (which RFC 5545 defines as inclusive). Both are DATE values (all-day); recurrences are date-based, so no time component is involved.

// Weekly stand-up, but only for July 2026
{ type: "weekly", id: "standup", dayOfWeek: 1,
startDate: "2026-07-01", endDate: "2026-07-31" }

optional startTime?: string


optional status?: "confirmed" | "tentative" | "cancelled"


optional templates?: Record<string, string>

Per-occurrence dynamic fields, derived from each occurrence’s date. A map of fieldName → template, where the template may contain date tokens ({YYYY} {MM} {DD} zero-padded · {M} {D} no padding). Each occurrence gets the field set to the interpolated value.

Applied during generation, after the base value and before a per-date exceptions[date].override (which always wins). Typically used for a date-specific url, but any string field works (title, description, location, …).

// Every Sunday's link points at a date page
{ type: "weekly", id: "mass", dayOfWeek: 0, title: "Mass",
templates: { url: "https://x.com/mass/{D}-{M}" } }
// 2026-07-07 → .../mass/7-7 · 2026-07-14 → .../mass/14-7

title: string


optional url?: string