fetchCalendars: accept calendars without supported-calendar-component-set

[ilyasturki]

Summary

fetchCalendars currently filters out any calendar whose supported-calendar-component-set property is empty or absent. Real-world CalDAV servers do this in violation of RFC 4791 § 5.2.3 — most notably Purelymail, which returns an empty <supported-calendar-component-set/> element on every calendar collection.

The earlier filter (Object.keys(resourcetype).includes('calendar')) has already confirmed the resource is a calendar by the time we reach the component-set check, so the second filter is acting as belt-and-suspenders defense rather than primary identification. When the property is absent, falling back to "accept" matches what tolerant clients like Thunderbird/Lightning, Evolution-DS, and DAVx5 do in practice.

Reproduction (against Purelymail)

import { DAVClient } from "tsdav";

const client = new DAVClient({
  serverUrl: "https://purelymail.com/",
  credentials: { username: "you@yours.com", password: "<app-password>" },
  authMethod: "Basic",
  defaultAccountType: "caldav",
});
await client.login();
console.log(await client.fetchCalendars());
// Before this PR: []
// After this PR: [{ url: "https://purelymail.com/webdav/<id>/caldav/default/", displayName: "Default", ... }]

DEBUG=tsdav:* confirms the full discovery chain succeeds (well-known redirect → principal → calendar-home-set) — only fetchCalendars swallows the actual calendar.

Diff summary

• src/calendar.ts: when extractComponentNames returns an empty array, accept the calendar instead of rejecting it.
• src/__tests__/unit/calendar.test.ts: regression test with two fixtures — empty supported-calendar-component-set element (Purelymail's actual shape) and the property being entirely absent.

Verification

• pnpm test — 186/186 unit tests pass (12 files), including 2 new fixtures.
• pnpm typecheck — clean.
• pnpm lint — clean for changed files (2 pre-existing errors in src/account.ts are unrelated to this PR).
• End-to-end against Purelymail's live CalDAV — fetchCalendars() now returns the Default calendar correctly; downstream fetchCalendarObjects and freeBusyQuery also work.

Compatibility

• Existing test "should filter out non-iCal calendars" still passes — calendars that explicitly declare a non-iCal component (e.g. UNKNOWN_TYPE) still get filtered out. Only the absent/empty case changes behavior.
• No public API surface change; no opt-out flag added (happy to add one if you'd prefer to keep strict-by-default).

[vercel]

@ilyasturki is attempting to deploy a commit to the llldar's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Copilot]

Pull request overview

Updates fetchCalendars to be more tolerant of real-world CalDAV servers that omit or return an empty supported-calendar-component-set, while keeping existing filtering behavior when components are explicitly declared.

Changes:

• Adjust calendar filtering to accept calendars when supported-calendar-component-set yields no component names.
• Add unit test coverage for calendars where supported-calendar-component-set is empty or absent.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/calendar.ts	Relaxes iCal component filtering to treat empty/missing component-set as “accept”.
src/__tests__/unit/calendar.test.ts	Adds regression test for empty and missing supported-calendar-component-set.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Test name says "supported-calendar-component-set is missing" but the fixture also covers the "present but empty" case (supportedCalendarComponentSet: {}); consider renaming the test to mention both (e.g. "missing or empty") or splitting into two tests to make the intent explicit.